Re: IETF 107 draft agenda planning

David Noveck <[email protected]> Mon, 18 Nov 2019 05:45:11 -0500
Newsgroups gmane.ietf.nfsv4
Message-ID <CADaq8jfO5NGqFQHa5a0yu=qZU4P_FA-eGH-hUikuFKwd5HcSqw@mail.gmail.com>
On Mon, Nov 18, 2019, 2:30 AM spencer shepler <[email protected]>
wrote:

>
>
> On Sun, Nov 17, 2019 at 11:05 PM David Noveck <[email protected]>
> wrote:
>
>>
>> On Wed, Nov 13, 2019, 1:52 PM Chuck Lever <[email protected]> wrote:
>>
>>> Reminder: IETF 107 is March 22 - 27 in Vancouver, CA.
>>>
>>> In a recent thread, Spencer Shepler said:
>>> > I would appreciate it if the WG spend some time in building a draft
>>> agenda so that content and schedule can be built.
>>>
>>
>> The draft agenda will be needed about two weeks before the meeting, i.e.
>> about four months from now.  Still, I think it makes sense to start the
>> planning process, as you have done, early although, given that things may
>> change between now and then, we want to retain some flexibility/agility.
>>
>
> Yes, that is correct.  A formal agenda is needed two weeks prior to the
> meeting.  I was attempting to respond to your earlier comments about
> needing to define the meeting content with enough advanced notice so that
> potential attendees could assess and plan their participation accordingly.
>

Fair enough.  However, especially with regard to this specific meeting, the
agenda details are not critical.  For this meeting the critical elements
are:

   - That Magnus has made clear that we need to make substantial progress
   on our existing agenda.

I expect people to decide to attend (whether remotely or in-person) based
on whether they think that agenda is important and are prepared to help,
rather than on whether they want to hear about one pariculrar document.


   - The fact that we have a sessions devoted to new ideas, both for
   protocol extensions and as far as new ways for us to do business, if we
   can.   I remember that both of these had trouble getting time in recent
   meetings and that Chuck's ideas in the latter ctegory were dropped from
   IET105 because of lack of time.

For the latter category people will make decisions based on items scheduled
for discussion.  However, they might also make decisions based on ideas
they want to present.  For that reason, we need to leave some free time for
late deciders although, it might be only a half-hour making it necessary
for late deciders to fight-it-out for working group interest.


My apologies if I didn't ask for that appropriately.
>

No issue there..


>
>>
>> I think we should plan based on the framework that Magnus has suggested:
>> one session devoted to the working group's current agenda and a second
>> about things for future consideration.
>>
>
> Is that 2 x 2.5 hours sessions or 2 x 1 hour sessions.
>

We don't know yet.  2.5-hour sessions might not be available but I feel
that at least two hours will be needed for the first session. For the
second session, we will have a better idea in about a month.


>
>>
>> As far as the first session, I would need some time to discuss matters
>> related to rfc5661bis and related documents. I'm guessing 30-40 minutes
>> will be needed.
>>
>
> Is there a reason that we are waiting 4 months before discussing this
> information?
>

There was a lot of discussion at IETF105. The discussion should be captured
in the minutes and the slides are available onthe web.

The thing holding up further work in this area is the uncertain state of
rfc5661sesqui. Since that document would be the base for the bis, I have
been staying away from bis issues until the fate of sesqui is clearer.

I hope that you have a plan to introduce these ideas prior to the
> face-to-face meeting such that there can be discussion of what plan to
> undertake with rfc5661bis.
>

I'll send something once I am clearer about the fate of sesqui


>
>>
>> As far as possible contributions to the second session, this is kind of
>> early, but I expect people to come up with interesting ideas.
>>
>> For my own part,  I'll be sending out a proposal for some topics (about
>> 20 minutes worth) in the next few weeks.
>>
>
> I hope, again, that these ideas can be discussed on the working alias
> prior to the meeting to garner wider feedback and input.
>

As I said, I will send something out in the next few weeks

I still doubt that in-person presence will be broad so capturing the
> valuable input from the email threads would be great.
>

Also, if there is no interest, there is no point getting a presentation
together


>
>>
>>
>>> I can start by listing the items I'm working on and what kind
>>> of meeting resources IMO might be needed for discussion. I'm
>>> going to assume that we will avoid "status reporting" here,
>>> and strive to use the meeting time mainly for interactive
>>> discussion of open questions.
>>>
>>
>> I anticipate there will be some need for status-related time in the first
>> session. Let's say five minutes. I hope we will be hearing from those with
>> active wg documents and/or milestones.  The critical areas requiring wg
>> consideration of status are for those documents not otherwise represented.
>>
>
> I would prefer that we stop making the face-to-face working group meetings
> status meetings.
>

I asked for five minutes. I don't understand the reaction.


> If there is status to report, put it into a paragraph or two and send it
> to the working group alias such that it is recorded, broadly disseminated.
> Much better use of everyone's time.
>

I disagree. If the status is that nobody is working on something important
or that a milestone date is unreachable, putting it in an email paragraph
makes it easy to forget about.

Since our approach to email will not accommodate a paragraph in 40-point
bold Arial Black saying "We're screwed", it is sometimes necessary to have
status discussions at face-to-face IETF meetings.


>
>>
>>
>>> - rpcrdma-cm-pvt-data: Hoping this will be published by March.
>>>
>>
>> Me too.
>>
>> In any event, no meeting time needed for this document.
>>>
>>
>> I sure hope not, given that the document was finished in June.
>>
>>
>>> - rpc-tls: I'm hoping this document will be in post-WG publication
>>> process in March. I anticipate there will be no need for meeting
>>> time for this work, unless something changes significantly.
>>>
>>
>> Part of the 5661bis discussion will be about security but I think the
>> role of rpc-tls will be as a base for what it is possible to do in a
>> revised v4 security framework.
>>
>>
>>> - rpcrdma-version-two: The protocol is nearing feature completion.
>>> I anticipate this may be in WGLC in March, but it might need
>>> further discussion. Let's say 15 minutes on this one.
>>>
>>
>> Sounds about right..
>>
>> Note that this document also has implications for the new security
>> framework, just as rpc-tls does.
>>
>>
>>> - integrity-measurement: I want to have an IMA metadata format
>>> document in draft form for this meeting. Let's say 15 minutes
>>> for this discussion.
>>
>>
>> That's reasonable although it is possible to not get a real resolution no
>> matter how much time we spend :-(
>>
>> In addition, we could schedule a phone call
>>> or two before March to get through the objections to the current
>>> document.
>>>
>>
>> I think we should do that and use the meeting time to make sure that
>> everyone is ok with whatever resolution was reached previously
>>
>
> Put them on the calendar and plan ahead.
>

I'm sure Chuck will do that when he thinks it would be productive.


>
> 2 weeks notice and the US holiday season is starting soon
>

Sure, but this is a case on which sooner is not necessarily better.


> Spencer
>

_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4