Subject: [nfsv4] Milestone draft for working group review

From: David Noveck <[email-masked]>
Date: Thu, 17 Aug 2017 07:35:37 -0400

We've previously discussed and reviewed a proposal for a new working group
charter.  The only thing missing was a set of proposed milestones.

Since that time, I've been discussing this subject with the authors of
active working group dcuments and I-D's that appear likely to become
working group documents (except for Benny HaLevy who seems to no longer be
active in the working group).  The draft of what we (Chuck, Tom, Christoph
and I) have come up with is attached, so that the working group can review
it.  I had assumed that others in the working group did not have any
proposed milestones that they would like to include and work on.  If I was
wrong about that, please bring any proposed new milestones to the attention
of the working group as part of this review.  If you have an idea for a
milestone which is not quite ready for this list, hold that thought.  There
is a mechanism for the working group to create new milestones later, once
the charter is approved.

It would be good if the working group could review this by Friday 8/25, so
that we can make any necessary adjustments and provide the chairs and ads
with a consolidated charter proposal including the stuff I sent to them on
7/31 but with the milestones included.  If anyone thinks theey need more
time to do this review, please let me know.

Most of the items on this list are not yet working group documents but I
hope I haven't included anything that people would object to becoming
working group documents.  If you do object or have issues with any of these
becoming working group douments, we need to address that as part of the
milestone review.

There are some notes below about the documents associated with the proposed
milestones, in time order.  Please let me know if you need any
clarification.

First are documents associated with the 2018 milestones:

The 3/2018 milestone is for the working group document deriving from
draft-hellwig-nfsv4-scsi-layout-nvme.  This document was discussed at
IETF99 and there was general agreement that it would become
standards-track.  There were a number of structural changes proposed at
that time and I assume Christoph is dealing with those before formally
requesting working group status for this document.

The 6/2018-10/2018 milestones all concern documents relating to changes for
trunking and state migration.  I presented slides about these at IETF99.
If these are not easily available, please let me know.  There are four
milestones and three documents as follows:

   - The 6/2018 milestone concerns draft-ietf-nfsv4-migration-issues.  It
   has become clear that fixing migration and trunking are inherently related
   so -13 has been retitled to reflect this fact.  If people have the time,
   I'd appreciate reviews of this document to make sure that we adress issue
   now, rather than in a rush at WGLC.  Although this document is
   informational, there will be a number of standards-track documents that
   derive from it.

   - The 8/2018 milestone concerns a document addressing trunking discovery
   in NFSv4.0.  This document addresses the same issues that had been dealt
   with in Andy's previous trunking discovery document although the treatment
   is significantly different.  In the IETF99 slides, the prospective I-D on
   which this will be based is referred to as
draft-adamson-nfsv4-mv0-truunking-update.

Since then, Andy has retired and his co-author Chuck Lever has agreed to
submit draft-cel--nfsv4-mv0-trunking-update, based on the work Andy has
already done.  I think Chuck will work on submitting this as soon as he has
had an opprtuunity to catch his breath after completing the work on the
last of the documents associated with RPC-over-RDMA version 1.  I expect to
be a co-author of the trunking update document and will work to keep the
trunking discussion for both minor versions consistent.

   - The two 10/2018 milestones will most likely be satisfied by the same
   docment, specfically the working group document to come, based on
   draft-dnoveck-nfsv4-mv1-msns-update.   I've previously promised to
   submit that I-D by the end of August and expect to be able to do that.

These are listed as two separate milestones because the working group has
not made any decision yet about how to go forward to address v4.1 issues
with regard to trunking and state migration.  If the working group decides
that these will be addressed in a single document, as I believe is best,
these two milestones can be coalesced.

One possible occasion for the working group to make this decision is when a
proposal is made to convert this document to working-group status.  Another
is to address this as part of the milestone review.  In any case, there is
no need to rush this decision since we could maintain these as two
milestones indefinitely.

Now let's look at the documents for the 2019 milestones:

The first 1Q2019 milestone is for a WG document deriving from
draft-cel-nfsv4-rpcrdma-cm-pvt-msg.  Although that document's current
proposed status is standards-track, Chuck has decided that the milestone is
for an anicipated informational document.  The working group can discuss
the issue of the document's status as part of the milestone review or when
Chuck formally asks to turn this into a working group document.  I
understandthat there may be controversy about the  issue, but I don''t
anticipte difficulty arrving at a consensus everyone can live with.

The other 1Q2019 milestone is for a WG document deriving from
draft-hellwig-nfsv4-rdma-layout.  As the discussion at IETF99 showed, there
are still significant issues to resolve before this document will be
complete.  I think we will want to identify those as part of the milestone
review, but it is not necesssary to address them now, or even when the
document becomes a WG document.  For those who think that Christoph's date
is optimistic/aggressive, I agree but feel that given the guidance we have
gotten from Spencer D., optimistic milestones are OK.  If, on the other
hand, you feel that Christoph has a date which is unachievable/delusional,
we can discuss that issue as part of milestone review.  If we do push that
date off and Christoph does get this done by 3/31/2019, then he gets to
tell all of us, "I told you so."

The 3Q2019 milestone, is for a WG document deriving from
draft-cel-nfsv4-rpcrdma-version-two, of which I am a co-author.  There are
still some technical issues to resolve, principally about the credit
mechanism, but those do not need to resolved as part of the milestone
review.  However, they do need to be identified so that we can go on to
resolve them as the document is refined further over the next two years.

---

From: Chuck Lever <[email-masked]>
Date: Mon, 21 Aug 2017 10:26:42 -0400

Happy eclipse day, Dave -

> On Aug 17, 2017, at 7:35 AM, David Noveck <[email-masked]> wrote:
> 
> We've previously discussed and reviewed a proposal for a new working group charter.  The only thing missing was a set of proposed milestones.
> 
> Since that time, I've been discussing this subject with the authors of active working group dcuments and I-D's that appear likely to become working group documents (except for Benny HaLevy who seems to no longer be active in the working group).  The draft of what we (Chuck, Tom, Christoph and I) have come up with is attached, so that the working group can review it.  I had assumed that others in the working group did not have any proposed milestones that they would like to include and work on.  If I was wrong about that, please bring any proposed new milestones to the attention of the working group as part of this review.  If you have an idea for a milestone which is not quite ready for this list, hold that thought.  There is a mechanism for the working group to create new milestones later, once the charter is approved.
> 
> It would be good if the working group could review this by Friday 8/25, so that we can make any necessary adjustments and provide the chairs and ads with a consolidated charter proposal including the stuff I sent to them on 7/31 but with the milestones included.  If anyone thinks theey need more time to do this review, please let me know.
> 
> Most of the items on this list are not yet working group documents but I hope I haven't included anything that people would object to becoming working group documents.  If you do object or have issues with any of these becoming working group douments, we need to address that as part of the milestone review.
> 
> There are some notes below about the documents associated with the proposed milestones, in time order.  Please let me know if you need any clarification.
> 
> The 3/2018 milestone is for the working group document deriving from draft-hellwig-nfsv4-scsi-layout-nvme.  This document was discussed at IETF99 and there was general agreement that it would become standards-track.  There were a number of structural changes proposed at that time and I assume Christoph is dealing with those before formally requesting working group status for this document.
> 
> The 6/2018-10/2018 milestones all concern documents relating to changes for trunking and state migration.  I presented slides about these at IETF99.  If these are not easily available, please let me know.  There are four milestones and three documents as follows:
> 	• The 6/2018 milestone concerns draft-ietf-nfsv4-migration-issues.  It has become clear that fixing migration and trunking are inherently related so -13 has been retitled to reflect this fact.  If people have the time, I'd appreciate reviews of this document to make sure that we adress issue now, rather than in a rush at WGLC.  Although this document is informational, there will be a number of standards-track documents that derive from it.
> 	• The 8/2018 milestone concerns a document addressing trunking discovery in NFSv4.0.  This document addresses the same issues that had been dealt with in Andy's previous trunking discovery document although the treatment is significantly different.  In the IETF99 slides, the prospective I-D on which this will be based is referred to as draft-adamson-nfsv4-mv0-truunking-update.  
> Since then, Andy has retired and his co-author Chuck Lever has agreed to submit draft-cel--nfsv4-mv0-trunking-update, based on the work Andy has already done.  I think Chuck will work on submitting this as soon as he has had an opprtuunity to catch his breath after completing the work on the last of the documents associated with RPC-over-RDMA version 1.  I expect to be a co-author of the trunking update document and will work to keep the trunking discussion for both minor versions consistent.
> 	• The two 10/2018 milestones will most likely be satisfied by the same docment, specfically the working group document to come, based on draft-dnoveck-nfsv4-mv1-msns-update.   I've previously promised to submit that I-D by the end of August and expect to be able to do that.  
> These are listed as two separate milestones because the working group has not made any decision yet about how to go forward to address v4.1 issues with regard to trunking and state migration.  If the working group decides that these will be addressed in a single document, as I believe is best, these two milestones can be coalesced.  
> 
> One possible occasion for the working group to make this decision is when a proposal is made to convert this document to working-group status.  Another is to address this as part of the milestone review.  In any case, there is no need to rush this decision since we could maintain these as two milestones indefinitely.
> 
> The first 1Q2019 milestone is for a WG document deriving from draft-cel-nfsv4-rpcrdma-cm-pvt-msg.  Although that document's current proposed status is standards-track, Chuck has decided that the milestone is for an anicipated informational document.  The working group can discuss the issue of the document's status as part of the milestone review or when Chuck formally asks to turn this into a working group document.  I understandthat there may be controversy about the  issue, but I don''t anticipte difficulty arrving at a consensus everyone can live with.
> 
> The other 1Q2019 milestone is for a WG document deriving from draft-hellwig-nfsv4-rdma-layout.  As the discussion at IETF99 showed, there are still significant issues to resolve before this document will be complete.  I think we will want to identify those as part of the milestone review, but it is not necesssary to address them now, or even when the document becomes a WG document.  For those who think that Christoph's date is optimistic/aggressive, I agree but feel that given the guidance we have gotten from Spencer D., optimistic milestones are OK.  If, on the other hand, you feel that Christoph has a date which is unachievable/delusional, we can discuss that issue as part of milestone review.  If we do push that date off and Christoph does get this done by 3/31/2019, then he gets to tell all of us, "I told you so." 
> 
> The 3Q2019 milestone, is for a WG document deriving from draft-cel-nfsv4-rpcrdma-version-two, of which I am a co-author.  There are still some technical issues to resolve, principally about the credit mechanism, but those do not need to resolved as part of the milestone review.  However, they do need to be identified so that we can go on to resolve them as the document is refined further over the next two years. 
> <NearFinalMilestoneDraft.pptx>

I have only very minor quibbles with any of this content, none worth
bringing up. This captures the bulk of what is ready to move forward,
and keeps the rate of publication roughly the same as its been for
the past five years. It's a good representation of the work before
us and the intent described in the proposed new Charter.

I suggested privately, and would like to bring up on the list, that
it would also be helpful to have a repository for our "stretch goals"
and "almost ready" or "wacky" ideas (thanks Bill Baker for that term).
It could help create an institutional memory, along with the mailing
list and IETF meeting notes (hint hint). We obviously have some worthy
ideas, as noted by Tom's "Next steps" presentation during IETF 99,
even if they aren't completely formed.

Speaking of institutional memory, I note that .pptx attachments do
not seem to be archived by either of the IETF's mailing list archive
tools. In one case, the attachment doesn't appear at all, and in the
other it is archived as a compressed file that doesn't seem to
re-inflate to anything useful.

Can you post subsequent revisions of the Charter and milestone list
only in ASCII text? That also makes it possible to simply hit "Reply"
and respond narrowly to individual parts of the text. Thanks!

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Mon, 21 Aug 2017 11:45:26 -0400

> bringing up.

If they are not brought up, then the draft I send to the chairs and ads
cannot include them.  Please make sure that you make me aware of
issues that need to be addressed, even if they might seem minor right
now.

> and "almost ready" or "wacky" ideas (thanks Bill Baker for that term).

Those are three different categories.  What I'm thinking about is
a list of "potential goals", which could include things that might
become goals if there were a person to take on the work and provide
a target date.  It could also include things that are not quite well-defined
enough for us to be sure about what document might really be done,
and ideas of various degrees of "wackiness", although we will try to
avoid things that the working group thinks are not worth considering.

> even if they aren't completely formed.

I will be producing that list, but it will take a while.  Maybe by the end
of
September.

I have looked at Tom's presentation and there are a number of items that
could be potential goals, although none is really "wacky".  In some of the
cases, the presentation isn't clear about what specific things the working
group
might do to further these ideas, but I can consult with Tom and Trond to
get the
necessary clarity.

> and respond narrowly to individual parts of the text. Thanks!

I'll do that, since the IETF seems to be stuck in the last century.  There
might somewhere be a plan to bring the IETF into the twenty-first century,
but, from what I've seen, 2099 might be too aggressive a target date :-(.

On Mon, Aug 21, 2017 at 10:26 AM, Chuck Lever <[email-masked]>
wrote:

> > We've previously discussed and reviewed a proposal for a new working
> group charter.  The only thing missing was a set of proposed milestones.
> >
> > It would be good if the working group could review this by Friday 8/25,
> so that we can make any necessary adjustments and provide the chairs and
> ads with a consolidated charter proposal including the stuff I sent to them
> on 7/31 but with the milestones included.  If anyone thinks theey need more
> > There are some notes below about the documents associated with the
> proposed milestones, in time order.  Please let me know if you need any
> clarification.
> >
> > The 6/2018-10/2018 milestones all concern documents relating to changes
> for trunking and state migration.  I presented slides about these at
> IETF99.  If these are not easily available, please let me know.  There are
> four milestones and three documents as follows:
> >       • The 6/2018 milestone concerns draft-ietf-nfsv4-migration-issues.
> It has become clear that fixing migration and trunking are inherently
> related so -13 has been retitled to reflect this fact.  If people have the
> time, I'd appreciate reviews of this document to make sure that we adress
> issue now, rather than in a rush at WGLC.  Although this document is
> >       • The 8/2018 milestone concerns a document addressing trunking
> discovery in NFSv4.0.  This document addresses the same issues that had
> been dealt with in Andy's previous trunking discovery document although the
> treatment is significantly different.  In the IETF99 slides, the
> prospective I-D on which this will be based is referred to as
> >       • The two 10/2018 milestones will most likely be satisfied by the
> same docment, specfically the working group document to come, based on
> draft-dnoveck-nfsv4-mv1-msns-update.   I've previously promised to submit
> that I-D by the end of August and expect to be able to do that.
> > These are listed as two separate milestones because the working group
> has not made any decision yet about how to go forward to address v4.1
> issues with regard to trunking and state migration.  If the working group
> decides that these will be addressed in a single document, as I believe is
> best, these two milestones can be coalesced.
> >
> > One possible occasion for the working group to make this decision is
> when a proposal is made to convert this document to working-group status.
> Another is to address this as part of the milestone review.  In any case,
> there is no need to rush this decision since we could maintain these as two
> milestones indefinitely.
> >
> draft-hellwig-nfsv4-rdma-layout.  As the discussion at IETF99 showed,
> there are still significant issues to resolve before this document will be
> draft-cel-nfsv4-rpcrdma-version-two, of which I am a co-author.  There
> are still some technical issues to resolve, principally about the credit

---

From: Chuck Lever <[email-masked]>
Date: Mon, 21 Aug 2017 12:08:58 -0400

Hi Dave-

> On Aug 21, 2017, at 11:45 AM, David Noveck <[email-masked]> wrote:
> 

Perhaps I should have said "No objections."

> a target date.

Thanks, looking forward to seeing it!

> It could also include things that are not quite well-defined

Our usual criterion for considering "wacky" ideas is a personal
I-D. I'm OK with placing these ideas in a "requires I-D"
category.

> I will be producing that list, but it will take a while.  Maybe by the end of
> September.
> 
> cases, the presentation isn't clear about what specific things the working group 
> might do to further these ideas, but I can consult with Tom and Trond to get the
> necessary clarity.

I'd like to see these items and any clarifications discussed
on-list first, or (preferably) in I-D form. Perhaps that's a
high bar, but the WG deserves a clear problem statement and
explanation of a proposed solution, so that it's members can
evaluate new ideas fairly.

> but, from what I've seen, 2099 might be too aggressive a target date :-(.

It's not just the IETF.

There are some on the list who cannot open a .pptx document.
There are some who refuse to, out of principal. There are
some who are behind corporate firewalls that discard e-mail
attachments as a policy, or that place size restrictions on
in-bound e-mail.

My own interest is archival, but I think we should strive for
inclusiveness.

> On Mon, Aug 21, 2017 at 10:26 AM, Chuck Lever <[email-masked]> wrote:

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Tue, 22 Aug 2017 08:15:45 -0400

> I-D.

Personal I-D's also discuss non-wacky ideas,  The wackiness of
any particular idea is a subjective judgment that different people will
make differently and that will change over time, with working
group discussion.

> I'm OK with placing these ideas in a "requires I-D"
> category.

I don't anticipate that the list I produce will be organized accoring
to categories of that sort.  In any case, I expect that it will contain:

   - Ideas for which there is an I-D and those for which there is no I-D
   (yet).
   - Ideas that I consider "wacky",but I'll try to filter out those that
   the entire working group is liable to find wacky.  In any case, subsequent
   workig group discussion could result in elimination of most of those.

> on-list

I'll make sure to copy the list on any discussion.

> first

Before what?,

> or (preferably) in I-D form.

That's certainly preferabe but my ability to get other people to write
documents, or even read them, is quite limited.

> Perhaps that's a
> high bar,

It certainly is.

> but the WG deserves a clear problem statement and

The question is at what point they actually need that.  I think it
is appropriate for the working group to insist on an I-D before embarking
on a working-group document and lately it has been doing that.

With regard to expectations for inclusion on the potential milestone
list, I don't think it makes sense to make the bar that high.  Doing that
would filter out too many "wacky" ideas before the working group has
had an opportunity to decide that they were not so wacky after all

On Mon, Aug 21, 2017 at 12:08 PM, Chuck Lever <[email-masked]>
wrote:

> > > It would be good if the working group could review this by Friday
> 8/25, so that we can make any necessary adjustments and provide the chairs
> and ads with a consolidated charter proposal including the stuff I sent to
> them on 7/31 but with the milestones included.  If anyone thinks theey need
> more time to do this review, please let me know.
> > >
> > > Most of the items on this list are not yet working group documents but
> I hope I haven't included anything that people would object to becoming
> > > The 6/2018-10/2018 milestones all concern documents relating to
> changes for trunking and state migration.  I presented slides about these
> at IETF99.  If these are not easily available, please let me know.  There
> are four milestones and three documents as follows:
> > > Since then, Andy has retired and his co-author Chuck Lever has agreed
> to submit draft-cel--nfsv4-mv0-trunking-update, based on the work Andy
> has already done.  I think Chuck will work on submitting this as soon as he
> has had an opprtuunity to catch his breath after completing the work on the
> > >       • The two 10/2018 milestones will most likely be satisfied by
> the same docment, specfically the working group document to come, based on

---

From: spencer shepler <[email-masked]>
Date: Wed, 23 Aug 2017 23:35:23 -0700

> My own interest is archival, but I think we should strive for

Dave,

Please go ahead and post the current draft charter and milestones to the WG
alias in text form so that we are inclusive as Chuck suggests.

Spencer

---

From: Chuck Lever <[email-masked]>
Date: Thu, 24 Aug 2017 10:55:11 -0400

> On Aug 22, 2017, at 8:15 AM, David Noveck <[email-masked]> wrote:
> 
> 	• Ideas for which there is an I-D and those for which there is no I-D (yet).
> 	• Ideas that I consider "wacky",but I'll try to filter out those that the entire working group is liable to find wacky.  In any case, subsequent workig group discussion could result in elimination of most of those. 

My opinion is based on recent experience with trying to assess the
content of Tom's IETF 99 "Next Steps" slides. Appealing topics,
all! But as I discussed these with various other members of the
Working Group, it became clear that each of us saw something mildly
or even vastly different in each bullet point. An I-D provides a
locus for consensus about each idea.

The other important piece of information that an I-D immediately
documents is it identifies stakeholders and those who are willing
to pursue the publication of the content.

A simple list of criteria for entertaining an idea, wacky or
otherwise, might be:

- Consensus around a problem statement

- One or more clearly expressed proposed solutions

- Someone (or ones) identified as the driver

- One or more WG members identified as reviewers or area experts

With a full set of these, we have an idea of what is to be addressed
and how; whether it is appropriate work for the WG to consider and
help with; and whose specific elbow grease will be applied to get
it published.

At that point, the content amounts to a short I-D anyway.

Hence "Requires I-D" would be a category of potentially interesting
ideas that are temporarily lacking one or more of the above criteria,
though we expect all will eventually be provided in some form.
Essentially this is a list containing I-D placeholders.

You can change the name, if "Requires" has an overly demanding tone.
Would "I-D Requested" be more inviting?

--
Chuck Lever

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 24 Aug 2017 19:07:33 +0000

-----Original Message-----
From: nfsv4 [mailto:[email-masked]] On Behalf Of Chuck Lever
Sent: Thursday, August 24, 2017 7:55 AM
To: David Noveck <[email-masked]>
Cc: [email-masked]
Subject: Re: [nfsv4] Milestone draft for working group review

> > Our usual criterion for considering "wacky" ideas is a personal I-D.
> 
> Personal I-D's also discuss non-wacky ideas,  The wackiness of any 
> particular idea is a subjective judgment that different people will 
> make differently and that will change over time, with working group 
> discussion.
>  
> > I'd like to see these items and any clarifications discussed on-list
> 
> > but the WG deserves a clear problem statement and explanation of a 
> > proposed solution, so that it's members can evaluate new ideas 
> > fairly.
> 
> The question is at what point they actually need that.  I think it is 
> appropriate for the working group to insist on an I-D before embarking 
> list, I don't think it makes sense to make the bar that high.  Doing 
> that would filter out too many "wacky" ideas before the working group 
> has had an opportunity to decide that they were not so wacky after all

My opinion is based on recent experience with trying to assess the content of Tom's IETF 99 "Next Steps" slides. Appealing topics, all! But as I discussed these with various other members of the Working Group, it became clear that each of us saw something mildly or even vastly different in each bullet point. An I-D provides a locus for consensus about each idea.

The other important piece of information that an I-D immediately documents is it identifies stakeholders and those who are willing to pursue the publication of the content.

A simple list of criteria for entertaining an idea, wacky or otherwise, might be:

With a full set of these, we have an idea of what is to be addressed and how; whether it is appropriate work for the WG to consider and help with; and whose specific elbow grease will be applied to get it published.

Hence "Requires I-D" would be a category of potentially interesting ideas that are temporarily lacking one or more of the above criteria, though we expect all will eventually be provided in some form.
Essentially this is a list containing I-D placeholders.

[Spencer] I would expect/hope that we have some threads of discussion on the WG alias to capture the items you mention, Chuck, and use as a method to resolve disparity in initial understanding and as initial content for a personal I-D - process/behavior that would help move things along.  So maybe something like "needs WG discussion and then personal I-D"

Spencer

---

From: David Noveck <[email-masked]>
Date: Thu, 24 Aug 2017 17:47:02 -0400

> A simple list of criteria for entertaining an idea, wacky or

This seems to me more like a list of criteria for pursuing an idea.

We should be open to entertaining ideas that don't (yet) meet these,
as long as there is an identifiable idea to consider.

We certainly need a problem statement and it wold be helpful if
it clearly enough expressed that everybody understands it the same way.

I wouldn't like to have to poll people as to whether they agrre to any
particular view so i would stay awat from the word  "consensus" .  Of
course, if somebody says he doesn't understand what the problem is,
we should deal with that.

> - One or more clearly expressed proposed solutions

Yes.

> - Someone (or ones) identified as the driver

I agree but I thhink we need more clarity on what we are asking of\the
driver(s).

> - One or more WG members identified as reviewers or area experts

This is helpful.  We have had too many cases in which documents are
not fully reviewed unti a mad rush at last call.  We should be paying more
attention to getting early review of documents.

> help with; and whose specific elbow grease will be applied to get

That is certainly enough for consideration as a potential milestone.

It might be past that point.  For example, you might consider this as a list
of criteria for making this a working group item.  So the question, is,
given these criuteria have been met, what else do you need to make
something
a working group item?

> At that point, the content amounts to a short I-D anyway.

At least a short one.

> though we expect all will eventually be provided in some form.

I don't see having this as a separate category.  You need the things
mentioned above and an I-D is a good way of providing them, but
having an I-d, does not, in itself, provide these things

> Essentially this is a list containing I-D placeholders.

It would contain those but it might also include I-D pointers, if I-D
an exists, but it isn't quite ready for some reason.

> Would "I-D Requested" be more inviting?

I'd handle it a different way.  The list/table would have a place for the
name
of the I-D or the designation "Not done (yet)".

I don't want to get into a required/requested/would-be-nice discussion.
The point is that your colleagues in the working group need this
information,
since they will want to know about your idea, and an I-D is one good way to
provide it.

On Thu, Aug 24, 2017 at 10:55 AM, Chuck Lever <[email-masked]>
wrote:

> >       • Ideas that I consider "wacky",but I'll try to filter out those
> that the entire working group is liable to find wacky.  In any case,
> subsequent workig group discussion could result in elimination of most of
> those.