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

From: Chuck Lever <[email-masked]>
Date: Wed, 5 Jul 2017 14:06:19 -0400

Hi Spencer-

Now that RFC 5666bis and rpcrdma-bidirection have been published,
it's time to push rfc5667bis. Is there anything more you need me
to do to get this going?

> On May 9, 2017, at 12:09 PM, spencer shepler <[email-masked]> wrote:
> 
> 
> Thanks, Chuck.  Will move this one forward.
> 
> On Tue, May 9, 2017 at 8:23 AM, Chuck Lever <[email-masked]> wrote:
> Hi Spencer-
> 
> Revision -11 includes yesterday's fixes discussed on list.
> Please consider this revision for IESG review.
> 
> 
> > Begin forwarded message:
> >
> > From: [email-masked]
> > Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-rfc5667bis-11.txt
> > Date: May 9, 2017 at 11:20:06 AM EDT
> > To: <[email-masked]>
> > Cc: [email-masked]
> >
> >
> > 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 Version One
> >        Author          : Charles Lever
> >       Filename        : draft-ietf-nfsv4-rfc5667bis-11.txt
> >       Pages           : 19
> >       Date            : 2017-05-09
> >
> > Abstract:
> >   This document specifies Upper Layer Bindings of Network File System
> >   (NFS) protocol versions to RPC-over-RDMA Version One, enabling the
> >   use of Direct Data Placement.  This document obsoletes RFC 5667.
> >
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc5667bis/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-nfsv4-rfc5667bis-11
> > https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rfc5667bis-11
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rfc5667bis-11
> >
> >
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/nfsv4
> 
> --
> Chuck Lever
> 
> 
> 
> 

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Wed, 12 Jul 2017 10:41:46 -0400

Hello chairs-

According to the datatracker, the document status is still
"WG Consensus: Waiting for Write-Up". Is there a reason this
document is not moving forward?

> On Jul 5, 2017, at 2:06 PM, Chuck Lever <[email-masked]> wrote:
> 
> Hi Spencer-
> 

--
Chuck Lever

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 12 Jul 2017 15:36:26 +0000

I will be moving this forward in the next day or two.

Spencer

-----Original Message-----
From: Chuck Lever [mailto:[email-masked]] 
Sent: Wednesday, July 12, 2017 7:42 AM
To: spencer shepler <[email-masked]>; Spencer Shepler <[email-masked]>; Brian Pawlowski <[email-masked]>; Brian Pawlowski <[email-masked]>; [email-masked]
Cc: NFSv4 <[email-masked]>; [email-masked]
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rfc5667bis-11.txt

Hello chairs-

According to the datatracker, the document status is still "WG Consensus: Waiting for Write-Up". Is there a reason this document is not moving forward?

> Now that RFC 5666bis and rpcrdma-bidirection have been published, it's 
> time to push rfc5667bis. Is there anything more you need me to do to 
> get this going?
> 
> 
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
>>> atracker.ietf.org%2Fdoc%2Fdraft-ietf-nfsv4-rfc5667bis%2F&data=02%7C0
>>> 1%7Csshepler%40microsoft.com%7C82d25a8220f94cc0ad0e08d4c93422a8%7C72
>>> f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636354673138046236&sdata=Dc
>>> rTGERG8sekgTJEKjZQ6sB1HuZdXdL54Y80Gh%2BOt50%3D&reserved=0
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo
>>> ls.ietf.org%2Fhtml%2Fdraft-ietf-nfsv4-rfc5667bis-11&data=02%7C01%7Cs
>>> shepler%40microsoft.com%7C82d25a8220f94cc0ad0e08d4c93422a8%7C72f988b
>>> f86f141af91ab2d7cd011db47%7C1%7C0%7C636354673138046236&sdata=djB5%2B
>>> gP66YykBioCn74JR6ZZCfF8lnPfes7nsmFQg44%3D&reserved=0
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
>>> atracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-nfsv4-rfc5667bis-11&data
>>> =02%7C01%7Csshepler%40microsoft.com%7C82d25a8220f94cc0ad0e08d4c93422
>>> a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636354673138056244&s
>>> data=CsWQhrcqhfwrba3AJJrpJUVZ5MFdKBErV1H4tRc4GLg%3D&reserved=0
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>>> .ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-nfsv4-rfc5667bis-11&data=02%
>>> 7C01%7Csshepler%40microsoft.com%7C82d25a8220f94cc0ad0e08d4c93422a8%7
>>> C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636354673138056244&sdata
>>> =0cQ3fCUdXwleo1nLwpclNJcv8N%2FRPuI97br9pxQ4mPc%3D&reserved=0
>>> 
>>> 
>>> 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.
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>>> .ietf.org%2Fmailman%2Flistinfo%2Fnfsv4&data=02%7C01%7Csshepler%40mic
>>> rosoft.com%7C82d25a8220f94cc0ad0e08d4c93422a8%7C72f988bf86f141af91ab
>>> 2d7cd011db47%7C1%7C0%7C636354673138056244&sdata=dV4MBa%2B97VEpd4TTdm
>>> hzhmWKwOyNsu9cvMdlS2ooU5A%3D&reserved=0
>> 
>> --
>> Chuck Lever
>> 
>> 
>> 
>> 
> 
> --
> Chuck Lever
> 
> 
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fnfsv4&data=02%7C01%7Csshepler%40microso
> ft.com%7C82d25a8220f94cc0ad0e08d4c93422a8%7C72f988bf86f141af91ab2d7cd0
> 11db47%7C1%7C0%7C636354673138056244&sdata=dV4MBa%2B97VEpd4TTdmhzhmWKwO
> yNsu9cvMdlS2ooU5A%3D&reserved=0

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Fri, 14 Jul 2017 12:53:52 -0400

I think the state definition in RFC6174 might help your search even though
it will
not, by itself, provide a reason:

4.2.9 <https://trac.tools.ietf.org/html/rfc6174#section-4.2.9>.  WG
Consensus: Waiting for Writeup

   A document in the "WG Consensus: Waiting for Writeup" state has
   essentially completed its development within the working group, and
   is nearly ready to be sent to the IESG for publication.  The last
   thing to be done is the preparation of a protocol writeup by a
   Document Shepherd.  The IESG requires that a document shepherd
   writeup be completed before publication of the I-D is requested.  The
   IETF document shepherding process and the role of a WG Document
   Shepherd is described in RFC 4858
<https://trac.tools.ietf.org/html/rfc4858> [RFC4858
<https://trac.tools.ietf.org/html/rfc4858>]

   A WG Chair may call consensus on an I-D without a formal WGLC and
   transition an I-D that was in the "WG Document" state directly into
   this state.

   The name of this state includes the words "Waiting for Writeup"
   because a good document shepherd writeup takes time to prepare.

So I guess you need to ask Spencer S. about the issues/difficulties
he is finding as he

prepares the writeup.  That might provide an explanation for the delay
we've seen so far,

although I expect that, given that two over months has elapsed, you
would prefer an ETA

in the near-future to an explanation.

On Wed, Jul 12, 2017 at 10:41 AM, Chuck Lever <[email-masked]>
wrote:

> submission