Subject: Re: [nfsv4] IETF 98 - NFSv4 WG meeting (soliciting agenda items)

From: David Noveck <[email-masked]>
Date: Fri, 7 Apr 2017 14:21:33 -0400

> The RFC Editor has responded and the I-D will be moving to AUTH48 within
the next week.

It is now five weeks later and  we've heard nothing to suggest AUTH48 is
any closer.  I'm

assuming that Spencer S. meant to put quote marks around the RFC Editor's
prediction.

Is here any way to get a reliable ETA on this, or at least some sort of
explanation for this
extraordinary delay?  After all, RFC 5661, which was over 600 pages long,
got through this
process in one month.

On Thu, Mar 2, 2017 at 11:31 AM, spencer shepler <[email-masked]>
wrote:

>
> The RFC Editor has responded and the I-D will be moving to AUTH48 within
> the next week.
>
> Spencer
>
>
> On Wed, Mar 1, 2017 at 3:16 PM, spencer shepler <[email-masked]
> > wrote:
>
>>
>> I have responded on the RFC editor thread. Will also follow-up with
>> Spencer D.
>>
>> Spencer
>>
>> On Wed, Mar 1, 2017 at 2:41 PM, Christoph Hellwig <[email-masked]> wrote:
>>
>>> On Tue, Feb 14, 2017 at 10:16:53AM -0500, David Noveck wrote:
>>> > Thirteen  days later, the document is still in MISSREF and appears not
>>> to
>>> > have moved forward
>>> > at all.  Maybe something has happened that I'm unaware of but it may be
>>> > that you are still
>>> > waiting for a response from the RFC editor.  Has there been a response
>>> yet,
>>> > or at least some sort of an ETA provided?
>>>
>>> Another two weeks later I've still not seen any respone since clarifying
>>> the references.
>>>
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>>
>>
>>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 8 Apr 2017 13:17:34 -0500

> Is here any way to get a reliable ETA on this, or at least some sort of

No.

> extraordinary delay?  After all, RFC 5661, which was over 600 pages long,

Maybe, eventually.

> process in one month.

The RFC Editor function has a fixed set of staff (on the order of 5,
if I understand correctly), and each proto-RFC gets assigned to one
of them for the initial/"mundane" editing.  If there's a large
collection of documents that hits the RFC Editor all at once, some
of them will get delays, even beyond the expected service level
specified in the contract for the RFC Editor function, though the
last I heard, the RFC Editor team was doing better at this after a
rough couple of years.  The actual named RFC Editor (Heather
Flanagan) does still make a final check over all RFCs, as I
understand it, so there is still a potential single point of
failure.  It's generally not easy to get great visibility into the
holdups of a specific document.  The triannual RFC Editor's report
presented (or emailed) at each IETF meeting generally includes
statistics on number of things published and conformance to the SLA,
though I either don't remember the numbers from the most recent one
in Chicago or didn't actually read it.

-Ben