Subject: [nfsv4] Contradiction between draft-ietf-nfsv4-rpcrdma-bidirection-03 and draft-ietf-nfsv4-rfc5666bis-05

From: David Noveck <[email-masked]>
Date: Tue, 3 May 2016 13:33:12 -0400

Section 7 of draft-ietf-nfsv4-rpcrdma-bidirection contains the following
(emphasis added):

By default, no data items in a ULP are DDP-eligible.  If there are no

DDP-eligible data items to document, *an explicit Upper Layer Binding*

*may not be needed *for an Upper Layer Protocol that operates only in

the backward direction.

On the other hand, Section 7 of draft-ietf-nfsv4-rfc5666bis says:

Each RPC Program and Version tuple that utilizes RPC-over-RDMA

Version One needs to have an Upper Layer Binding specification.

In my review of draft-ietf-nfsv4-rpcrdma-bidirection-03, I'm going to
assume that the handling
in the bidirection document will stay as it is and that rfc5666bis will be
changed to match.

Chuck should let me know if he wants to address this differently.

---

From: Chuck Lever <[email-masked]>
Date: Tue, 3 May 2016 13:46:46 -0400

> On May 3, 2016, at 1:33 PM, David Noveck <[email-masked]> wrote:
> 
> Section 7 of draft-ietf-nfsv4-rpcrdma-bidirection contains the following (emphasis added):
> 
> DDP-eligible data items to document, an explicit Upper Layer Binding
> may not be needed for an Upper Layer Protocol that operates only in
> the backward direction.

> In my review of draft-ietf-nfsv4-rpcrdma-bidirection-03, I'm going to assume that the handling
> in the bidirection document will stay as it is and that rfc5666bis will be changed to match.  
> 

It's a question mark. We could require a ULB for backward
direction operation.

If chunks are to be used, a ULB would be required, of
course.

But since backward direction operation occurs on an already-
established connection, there's no need to specify RPC
bind parameters. And by default, no XDR data item is
DDP-eligible.

A ULB for a backward-direction-only RPC Program with no
large data payloads might be very short.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Tue, 3 May 2016 14:03:34 -0400

> It's a question mark.

The IESG won't accept a question mark.  I'm OK with a coin flip.

> large data payloads might be very short.

There might never be any backward-direction-only ULBs (as opposed to
bi-directional ones).

Such a document would need security considerations, an IANA section and
might fit in three pages.  To publish it as a proposed standard would take
about six months.  Sigh!

---

From: Chuck Lever <[email-masked]>
Date: Tue, 3 May 2016 14:31:07 -0400

> On May 3, 2016, at 2:03 PM, David Noveck <[email-masked]> wrote:
> 
> > It's a question mark.
> 
> There might never be any backward-direction-only ULBs (as opposed to bi-directional ones).

Then there are two cases that can be described in
Section 7 of rpcrdma-bidirection:

1. Backward-direction operations specified as part of an
RPC Program that operates largely in the forward
direction (eg, a bi-directional program like NFSv4.1).

The backward ULB must be part of the ULB for the forward
direction. If backward-direction operations and data items
are not mentioned in that ULB, none of them are DDP-eligible.

2. Backward-direction only Programs.

I think an explicit ULB is required here, and can contain
security and IANA considerations, as well as other items
mentioned in rfc5666bis.

Does any of that contradict rfc5666bis Section 7?

> Such a document would need security considerations, an IANA section and might fit in three pages.  To publish it as a proposed standard would take about six months.  Sigh!
> 

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Tue, 3 May 2016 16:50:38 -0400

> Section 7 of rpcrdma-bidirection:

Right now, section 7 is written, or seems as if it is written, only
addressing your case #2 below.  Part of my review will suggest
ways of addressing that.

> direction (eg, a bi-directional program like NFSv4.1).

Right.  That's the obvious case that seems to be missing in section 7.

> are not mentioned in that ULB, none of them are DDP-eligible.

Yes, but the point has to be made that the fact that the XDR describes
these as two
separate programs does not get in the way.

> security and IANA considerations, as well as other items

My review will take that approach.  I don't care about this case, as it is
unlikely to
happen in real life.

> Does any of that contradict rfc5666bis Section 7?

I don't think so.  The cases that might have rfc5666bis implications are
limited
to issues related to minor versioning and extensions.

   - A protocol that was previously used only in the forward direction
   becomes bidirectional (only theoretical).
   - A protocol is extended to get new DDP-eligible backward-direction XDR
   items. (might happen to v4,.x some day).