Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-rfc5667bis-05.txt

From: [email-masked]
Date: Fri, 03 Feb 2017 09:20:19 -0800

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 of the IETF.

        Title           : Network File System (NFS) Upper Layer Binding To RPC-Over-RDMA
        Author          : Charles Lever
	Filename        : draft-ietf-nfsv4-rfc5667bis-05.txt
	Pages           : 17
	Date            : 2017-02-03

Abstract:
   This document specifies Upper Layer Bindings of Network File System
   (NFS) protocol versions to RPC-over-RDMA.  Upper Layer Bindings are
   required to enable RPC-based protocols, such as NFS, to use Direct
   Data Placement on RPC-over-RDMA.  This document obsoletes RFC 5667.

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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-nfsv4-rfc5667bis-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rfc5667bis-05

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/

---

From: Chuck Lever <[email-masked]>
Date: Fri, 3 Feb 2017 12:28:01 -0500

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-rfc5667bis-05.txt
> Date: February 3, 2017 at 12:20:19 PM EST
> To: <[email-masked]>
> Cc: [email-masked]
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

The goal of this revision is to checkpoint changes made in response
to recent discussion on list.

- The use of short Reply chunk retry has been narrowed

- The discussion of NFS session operation on RPC-over-RDMA
  transports has been clarified

- The discussion of connection loss handling has been
  made more detailed

- More DDP mechanism-specific language has been removed

Specific discussion of the use of Write chunks remains in sections
dealing with matching up Write chunks to DDP-eligible results. Any
thoughts on whether the discussion of these details is appropriate
or should be replaced or removed?

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Fri, 3 Feb 2017 13:30:50 -0500

In deciding this, the critical section is:

The mechanism specified in Section 4.3.2 of

I-D.ietf-nfsv4-rfc5666bis]) is applied here, with additional

restrictions that appear below.

As it is, one can't tell what part of the matching procedure is derived from
rfc566bis and what part is NFSv4-specific.

BTW, I'll have the same issue in nfsulb, were I have a couple of additional
issues:

   - The means by which the placement of response data is specified is not
   always a "write chunk"
   - rtrext allows the requester to limit the scope of specificaion for the
   placement of response data to specific operations within a COMOUND.

---

From: karen deitke <[email-masked]>
Date: Fri, 3 Feb 2017 17:11:57 -0700

Section 3.1.2 had information that is a duplicate of info in 4.2.1. Is 
it really needed in both places?  4.2.1 has more details so maybe 3.1.2 
should just refer to 4.2.1

4.6 says "Then the NFS version 4 rules for handling retransmission 
apply" ...what if this is an nfsv3 request?  The next paragraph also 
talks about v4 rules, but this section is specific to retransmission and 
keepalive, but does not indicate it is specific to v4, so seems 
confusing.  Oh, but I see later:

    A section discussing NFS version 4 retransmission and connection loss
    has been added.

So this section was specific to v4 (which makes sense regarding the v4 
retry only on a new connection rule, but at first it was confusing).

Karen

---

From: Chuck Lever <[email-masked]>
Date: Mon, 6 Feb 2017 11:16:32 -0500

> On Feb 3, 2017, at 7:11 PM, karen deitke <[email-masked]> wrote:
> 
> Section 3.1.2 had information that is a duplicate of info in 4.2.1. Is it really needed in both places?  4.2.1 has more details so maybe 3.1.2 should just refer to 4.2.1

Each section refers to specific actions for a particular NFS operation,
in the context of particular NFS versions.

Section 4.2.1 has to deal additionally with NFSv4 COMPOUND requests that
combine GETATTR with other operations that could be idempotent.

Though the content looks similar, I felt the sections were different
enough that they should be separate.

> 4.6 says "Then the NFS version 4 rules for handling retransmission apply" ...what if this is an nfsv3 request?  The next paragraph also talks about v4 rules, but this section is specific to retransmission and keepalive, but does not indicate it is specific to v4, so seems confusing.  Oh, but I see later:
> So this section was specific to v4 (which makes sense regarding the v4 retry only on a new connection rule, but at first it was confusing).

Yes, this subsection is in the "NFSv4 Upper Layer Binding" section,
and refers only to NFSv4.

So that brings up two questions:

1. Is there anything worth saying about NFSv3 retransmission?

2. Is there anything I can add that will help resolve confusion
about the purpose of section 4.6?

>>> Cc: 

--
Chuck Lever

---

From: karen deitke <[email-masked]>
Date: Mon, 6 Feb 2017 09:22:30 -0700

> enough that they should be separate.
OK makes sense.
> about the purpose of section 4.6?
No, I think that's good.  I needed to look again at the section title of 
"4. Upper Layer Binding for NFS Version 4".  When reading 4.6 I didn't 
consider this as all under 4.

Karen