Re: [nfsv4] rfc5666bis and rpcrdma-bidirection progress update

[David Noveck <[e-mail]>]

> Yes, I am the bottleneck on some of this but I get one nag email every
few weeks.

It appears that you will soon be getting more, as the implication of your
remarks is that, if you are not reminded frequently, things will be judged
non-urgent and simply not get done.

> Mmm, yes, it has slipped on my todo list but I also have not been
reminded with any great frequency

What frequency of reminder would be necessary to get to do what you have
already committed yourself to do?

I can remind you weekly or daily, if you choose.

> is it urgent or not.

Well, nobody's life depends on it.  But, we have a serious problem with
regard to our RDMA transport and Chuck and others have devoted considerable
work to rectifying it.   You are, unintentionally, standing in the way of
that work coming to fruition.  As understand it, that is why Chuck reminded
you of the need to proceed on this and why you told him it would get done
soon.  I don't think  that Chuck needs to take on the work of reminding you
to do what you have said you will do.   I think it would make more sense if
you, when you became unable to do what you said you would, asked Chuck
about priorities.

> Yes, I can improve my cycle time but there are many other steps involved
and just waving that it is “IETF Process” is unsatisfactory from my point
of view.

I've tried to break it up to specific elements, and I may have appeared
unfair in pointing to areas where you were the bottleneck.

There has been difficulty in getting people to actually read and comment on
some of the extension documents, but, beyond pointing out that fact, I
don't see what else I can do.

> It is what you make of it. The elapsed time can be reduced –
unfortunately, much of the slowness is self-induced (working group
self-induced)

I suppose you mean "induced by others than the WG chair", in which case I
agree.

> indicative of the relative priorities of everyone involved.

True but in the particular case of the RDMA documents, the authors and the
working group have treated this as  of high priority while you have not,
since you were not pelted with frequent reminders. I think that is the
source of complaints about the "excrucuiating sluggishness" of the process.

For other documents, the balance has been different.

On Mon, Nov 28, 2016 at 1:12 PM, Spencer Shepler <[e-mail]>
wrote:

>
>
> My comments were general, Dave.  Yes, I am the bottleneck on some of this
> but I get one nag email every few weeks.  Mmm, yes, it has slipped on my
> todo list but I also have not been reminded with any great frequency – is
> it urgent or not.
>
>
>
> Yes, I can improve my cycle time but there are many other steps involved
> and just waving that it is “IETF Process” is unsatisfactory from my point
> of view.  It is what you make of it. The elapsed time can be reduced –
> unfortunately, much of the slowness is self-induced (working group
> self-induced) and indicative of the relative priorities of everyone
> involved.
>
>
>
> Spencer
>
>
>
> *From:* David Noveck [mailto:[e-mail]]
> *Sent:* Monday, November 28, 2016 9:33 AM
> *To:* Spencer Shepler <[e-mail]>
> *Cc:* Chuck Lever <[e-mail]>; [e-mail]
>
> *Subject:* Re: [nfsv4] rfc5666bis and rpcrdma-bidirection progress update
>
>
>
> With regard to these documents I suppose that it is appropriate to remind
> you of the history here:
>
>    - These documents have been in the state WG Consensus:Waiting for
>    Writeup for over four months, since 7/19.
>    - Chuck tried to reduce the workload by deciding to drop the
>    associated informational document.
>    - Chuck made efforts to remind you of the need to provide these
>    writeups.
>    - This appeared to culminate in your statement  on 10/25: " For the
>    I-Ds that are "waiting for write-up", those are on my to-do list and will
>    be out in the next week"
>    - It is now about five weeks since that statement and we have heard
>    nothing about progress in this regard.
>
> > Reminders, regularly scheduled conference calls, changing ownership,
> breaking the tasks into smaller items, discarding unneeded functionality to
> move the process forward.
>
>
>
> We've tried reminders and Chuck did remove unnecessary work.  However, the
> IETF rules don't appear to allow changing ownership of the task of
> producing a wrIteup.  If you think that is appropriate, then perhaps you
> should investigate it.  Given that there is a bunch of other documents that
> will soon be in the same state, maybe you should consider that.  Would
> regularly scheduled conference help, or would they just take up time?
>
>
>
> > most of it is under the control of the authors and the collective
> working group once there is consensus that an I-D is a WG draft.
>
>
>
> True, but there is a significant portion of the process where we wind up
> waiting for action by the WG chair, and for these documents, that has been
> a considerable portion of the delay.  Is there a viable way to spread out
> this work better?
>
>
>
>
>
>
>
> On Mon, Nov 28, 2016 at 11:53 AM, Spencer Shepler <[e-mail]>
> wrote:
>
>
>
> For this comment, “If we want to improve the process, and I believe we
> should, we need to focus on review quality/adequacy as well as the pace of
> the process.”
>
>
>
> If there is a desire for an item to move more quickly, treat it like any
> other item in life – take responsibility for it, invest the time, get
> others that are needed to do the same.
>
>
>
> There are a variety of techniques for managing work that is done by
> others.  Reminders, regularly scheduled conference calls, changing
> ownership, breaking the tasks into smaller items, discarding unneeded
> functionality to move the process forward.
>
>
>
> The “process” can move more quickly if desired – at least for the items
> that are under direct control and in the case of Internet Drafts – most of
> it is under the control of the authors and the collective working group
> once there is consensus that an I-D is a WG draft.
>
>
>
> Spencer
>
>
>
> *From:* nfsv4 [mailto:[e-mail]] *On Behalf Of *David Noveck
> *Sent:* Sunday, November 27, 2016 3:55 AM
> *To:* Chuck Lever <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [nfsv4] rfc5666bis and rpcrdma-bidirection progress update
>
>
>
> So the review process will not be interrupted.  It will continue at the
> same pace as before.
>
> With regard to the characterization of the process as "excruciatingly
> sluggish", it does seem that not very much has happened since the working
> group reached consensus on  this document on 4/17/2016 (according to the
> data tracker history).
>
> However, to be fair, we should note that draft-ietf-nfsv4-rfc5666bis-00
> was submitted on 12/01/2015 and it it took the working group less than a
> year to get to the point we are.    It looks likely to me that the whole
> process will (cross your fingers) be completed in around 16 months from
> first submission.   It is hard to get documents done faster than that
> within the IETF process, which is not optimized for speed.
>
> Contrast that with RFC5666 itself which took over five years from -00
> submission to RFC publication.  Despite the slow pace of the process, it
> appears that the document did not get the kind of review it needed before
> publication, making rfc5666bis necessary. I'd like to thank the authors for
> persevering in the effort to provide NFS with an RDMA-based transport.
>
> If we want to improve the process, and I believe we should, we need to
> focus on review quality/adequacy as well as the pace of the process.
>
>
>