Subject: Re: [nfsv4] Publication has been requested for draft-ietf-nfsv4-rpcrdma-cm-pvt-data-04

From: David Noveck <[email-masked]>
Date: Sat, 2 Nov 2019 06:37:25 -0400

Looking at the document status, there is a problem that needs to
be corrected.  "Consensus" is shown incorrectly as "Unknown".  In fact, as
is well-known within the working group and documented in the Shepherd's
write-up, there is a working group consensus to proceed with IESG
consideration and eventual publication of this document.

On Thu, Oct 31, 2019, 1:10 PM Spencer Shepler via Datatracker <
[email-masked]> wrote:

> Spencer Shepler has requested publication of
> draft-ietf-nfsv4-rpcrdma-cm-pvt-data-04 as Informational on behalf of the
> NFSV4 working group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcrdma-cm-pvt-data/
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 4 Nov 2019 12:29:56 +0000

Hi David,

So, I have fixed that field. I don't know if this was oversight in setting some
field in the publication reuqest by Brian or something else. 

Cheers

Magnus

On Sat, 2019-11-02 at 06:37 -0400, David Noveck wrote:
> be corrected.  "Consensus" is shown incorrectly as "Unknown".  In fact, as is
> well-known within the working group and documented in the Shepherd's write-up, 
> there is a working group consensus to proceed with IESG consideration and
> eventual publication of this document.
> 
> > Spencer Shepler has requested publication of draft-ietf-nfsv4-rpcrdma-cm-
> > pvt-data-04 as Informational on behalf of the NFSV4 working group.
> > 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 4 Nov 2019 14:53:17 +0000

Hi,

The issue, is that the draft says Intended Status: Informational. The write-up
says standard track (Proposed Standard). Based on the content I think the later
is true. However, the fact that the datatracker thought it was an inforamational
document it didn't automatically set it, and it falls upon the AD to make it
clear if informational or experimental documents have IETF consensus or not. 

Cheers

Magnus

On Mon, 2019-11-04 at 12:29 +0000, Magnus Westerlund wrote:
> > is
-- 
Cheers

Magnus Westerlund

---

From: Chuck Lever <[email-masked]>
Date: Mon, 4 Nov 2019 09:55:54 -0500

Hi Magnus-

> On Nov 4, 2019, at 9:53 AM, Magnus Westerlund <magnus.westerlund=[email-masked]> wrote:
> 
> Hi,
> 
> is true.

We intentionally made this an Informational document.

> However, the fact that the datatracker thought it was an inforamational
> clear if informational or experimental documents have IETF consensus or not.. 
> 
> Cheers
> 
> Magnus
> 
> 

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 5 Nov 2019 09:56:38 +0000

Hi,

Removing the IESG-Secretary and [email-masked] address. 

On Mon, 2019-11-04 at 09:55 -0500, Chuck Lever wrote:
> Hi Magnus-
> 
> > On Nov 4, 2019, at 9:53 AM, Magnus Westerlund <
> > magnus.westerlund=[email-masked]> wrote:
> > 
> > Hi,
> > 

Okay, that is not what the write-up said. Also, it does not read like an
informational document. So, please provide me with the motivation why this
should be published as an informational RFC. What I can see this is an extension
to at least one IETF defined standards track document. I need to understand why
the WG thinks it should be informational. 

Cheers

Magnus Westerlund

---

From: spencer shepler <[email-masked]>
Date: Tue, 5 Nov 2019 07:40:26 -0800

Magnus,

I did a quick update to the tool and went off the header of the I-D - it is
marked as informational.

As you say, this should be on standards track.  So we have a quick tool
update to do and when Chuck revs his document, he will just update.

On Tue, Nov 5, 2019 at 1:56 AM Magnus Westerlund <
[email-masked]> wrote:

> > > The issue, is that the draft says Intended Status: Informational. The
> write-
> > > up
> > > says standard track (Proposed Standard). Based on the content I think
> the
> > > later
> > > is true.
> >

---

From: Tom Talpey <[email-masked]>
Date: Tue, 5 Nov 2019 17:22:01 +0000

TL;DR Proposed Standard is appropriate.

Longer version, I may be the guilty party here. When Chuck originally was exploring using private data to extend rpcrdmav1, I encouraged him to publish the format as a draft. By design, the private data is optional, for both the sender and the receiver. Its presence, and its recognition at the peer, drives the extended features.

At the time, the concern for standardization was whether it would be of interest to the WG, and/or to other implementations. Its adoption as a WG item settles that.

When published as Proposed Standard, the document should additionally be tagged as an optional extension to RFC8166.

From: nfsv4 <[email-masked]> On Behalf Of spencer shepler
Sent: Tuesday, November 5, 2019 10:40 AM
To: Magnus Westerlund <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] Publication has been requested for draft-ietf-nfsv4-rpcrdma-cm-pvt-data-04

Magnus,

I did a quick update to the tool and went off the header of the I-D - it is marked as informational.

As you say, this should be on standards track.  So we have a quick tool update to do and when Chuck revs his document, he will just update.

On Tue, Nov 5, 2019 at 1:56 AM Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Removing the IESG-Secretary and [email-masked]<mailto:[email-masked]> address.

On Mon, 2019-11-04 at 09:55 -0500, Chuck Lever wrote:
> > magnus.westerlund=[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Hi,
> >

Cheers

Magnus Westerlund

SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>

---

From: Chuck Lever <[email-masked]>
Date: Tue, 5 Nov 2019 12:30:12 -0500

If the AD and the WG support the change, then the next revision of this
document will be internally changed to Proposed Standard, and I will
tag it as an update to RFC 8166.

NB: The draft submission window is closed until November 16.

> On Nov 5, 2019, at 12:22 PM, Tom Talpey <ttalpey=[email-masked]> wrote:
> 
> On Tue, Nov 5, 2019 at 1:56 AM Magnus Westerlund <[email-masked]> wrote:
> Hi,
> 

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 6 Nov 2019 13:22:27 +0000

> NB: The draft submission window is closed until November 16.

If there is no WG disagreement the next few days, please go ahead and change. As
AD I think it is appropriate to publish this as standards track, especially if
it can be made clear that this optional extension is usable in at least one IETF
protocol and potentially others. 

Regarding the draft submission lock down. Send me the updated document when you
addressed all the issues and I will get it posted. This will be manually handled
, but I see no reason for not getting the draft posted.

Cheers

Magnus

> 
> 
> > On Nov 5, 2019, at 12:22 PM, Tom Talpey <
> > ttalpey=[email-masked]> wrote:
> > 
> > Longer version, I may be the guilty party here. When Chuck originally was
> > exploring using private data to extend rpcrdmav1, I encouraged him to
> > publish the format as a draft. By design, the private data is optional, for
> > both the sender and the receiver. Its presence, and its recognition at the
> > peer, drives the extended features.
> >  
> > At the time, the concern for standardization was whether it would be of
> > interest to the WG, and/or to other implementations. Its adoption as a WG
> > item settles that.
> >  
> > When published as Proposed Standard, the document should additionally be
> > tagged as an optional extension to RFC8166.
> >  
-- 
Cheers

Magnus Westerlund

---

From: Chuck Lever <[email-masked]>
Date: Wed, 6 Nov 2019 10:53:21 -0500

Hi Magnus-

> On Nov 6, 2019, at 8:22 AM, Magnus Westerlund <[email-masked]> wrote:
> 

I can get the editorial changes done today, but submission will depend on
resolving the issue with that stale IBTA URL.

Because there is a registration wall, I expect that the IBTA will not be
willing to provide a permanent URL. Perhaps this reference could be changed
to a true bibliographic citation.

Thoughts, opinions, anyone?

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Wed, 6 Nov 2019 11:23:14 -0500

Hi everyone (but especially Tom) -

> When published as Proposed Standard, the document should additionally be tagged as an optional extension to RFC8166.

To address this issue, I've made the following changes to the document.
Please let me know if additional changes are needed. I plan to separately
address the other issues arising from the AD write-up.

The status has been changed:

Network File System Version 4                                   C. Lever
Internet-Draft                                                    Oracle
Updates: 8166 (if approved)                             November 6, 2019
Intended status: Standards Track
Expires: May 9, 2020

The Abstract now reads:

   This document specifies the format of RDMA-CM Private Data exchanged
   between RPC-over-RDMA version 1 peers as part of establishing a
   connection.  The addition of the private data payload specified in
   this document is an OPTIONAL extension that does not alter the RPC-
   over-RDMA version 1 protocol.  This document updates RFC 8166.

A paragraph has been added near the end of the Introduction:

...
   the base RPC-over-RDMA version 1 protocol defined in [RFC8166].

   To enable current RPC-over-RDMA version 1 implementations to
   interoperate with implementations that support the message format
   described in the current document, the private message is not
   required to be present, and the message format does not alter the XDR
   definition of the RPC-over-RDMA version 1 protocol.  When the private
   message is not present, implementations conform to the defaults
   already found in [RFC8166].

   The message format is intended to be further extensible within the
...

--
Chuck Lever

---

From: Tom Talpey <[email-masked]>
Date: Wed, 6 Nov 2019 16:40:47 +0000

Looks good, but I think the RFC2119 "OPTIONAL" is inappropriate in the Abstract.
It should be simply "optional" here. It should perhaps be repeated in the body in
normative form.

In the new paragraph, "described in the current document" is a bit vague. Suggest
"conforming to RFC8166".

The final sentence of the new paragraph can be restated a bit, to make the OPTIONAL
statement as well as making it explicit that RFC8166 conformance doesn't change:

"Support for the private data payload specified in this document is OPTIONAL. When
the private data payload is successfully exchanged, peers MAY perform the extended
RDMA semantics. The RFC8166 protocol itself is unchanged."

That's a suggestion, better wording is fine too.

Tom.

-----Original Message-----
From: Chuck Lever <[email-masked]> On Behalf Of Chuck Lever
Sent: Wednesday, November 6, 2019 11:23 AM
To: Tom Talpey <[email-masked]>
Cc: spencer shepler <[email-masked]>; Magnus Westerlund <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [nfsv4] Publication has been requested for draft-ietf-nfsv4-rpcrdma-cm-pvt-data-04

The Abstract now reads:

....

....

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Wed, 6 Nov 2019 13:40:48 -0500

> On Nov 6, 2019, at 11:40 AM, Tom Talpey <[email-masked]> wrote:
> 

idnits did not complain about this, but I've changed it as suggested.

> RDMA semantics. The RFC8166 protocol itself is unchanged."

Not sure about using MAY here. MAY usually means "you shouldn't, but
there are some cases where it might be necessary." Not even sure if
SHOULD or MUST captures the precise intention.

And, "RFC8166 protocol itself is unchanged" is not strictly true: When
Remote Invalidation is in use, Send With Invalidate may be used on the
wire instead of Send. The XDR definition is definitely unchanged,
however.

> That's a suggestion, better wording is fine too.

After updating, here's what I have:

Abstract

   this document is an optional extension that does not alter the RPC-

Introduction

...

   To enable current RPC-over-RDMA version 1 implementations to
   interoperate with implementations that support the message format
   described in this document, the private message is not required to be
   present, and the message format does not alter the XDR definition of
   the RPC-over-RDMA version 1 protocol.  In other words, implementation
   of the private data message specified in this document is OPTIONAL.
   When the private message is not present, implementations strictly
   conform to [RFC8166].

...

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Wed, 6 Nov 2019 13:50:54 -0500

> On Nov 6, 2019, at 1:40 PM, Chuck Lever <[email-masked]> wrote:
> 
>> 

Re-reading your proposed text, it says exactly what I said here. Sigh!

> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>

--
Chuck Lever

---

From: Tom Talpey <[email-masked]>
Date: Wed, 6 Nov 2019 18:56:58 +0000

Sorry about this top-post, but it'll get ugly if I switch modes in Outlook.

Regarding my suggestion of MAY, yes perhaps the normative form is inappropriate.
How about "may"? Or "may elect to"?

-----Original Message-----
From: Chuck Lever <[email-masked]> On Behalf Of Chuck Lever
Sent: Wednesday, November 6, 2019 1:41 PM
To: Tom Talpey <[email-masked]>
Cc: spencer shepler <[email-masked]>; Magnus Westerlund <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [nfsv4] Publication has been requested for draft-ietf-nfsv4-rpcrdma-cm-pvt-data-04

Abstract

Introduction

...

...

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Wed, 6 Nov 2019 13:59:42 -0500

Here's my final answer ;-)

   To enable current RPC-over-RDMA version 1 implementations to
   interoperate with implementations that support the private message
   format described in this document, implementation of the private data
   message is OPTIONAL.  When the private data message has been
   successfully exchanged, peers may choose to perform extended RDMA
   semantics.  However, the private message format does not alter the
   XDR definition specified in [RFC8166].

> On Nov 6, 2019, at 1:56 PM, Tom Talpey <ttalpey=[email-masked]> wrote:
> 

--
Chuck Lever