Subject: [Int-area] Steps to make the IntArea WG more productive

From: Scott Brim <[email-masked]>
Date: Mon, 2 May 2011 19:17:53 -0400

Folks, the IntArea WG meeting in Prague was frustrating for some
because there was not enough discussion time among the presentations.
We have been talking about ways to do better, and how to make it easier
for the WG to be productive.

One potential improvement is more effective use of the mailing list.
If we systematically investigate issues on the mailing list,
participants can go into the face-to-face meeting feeling like they
have a clear understanding, energized and ready for passionate
discourse.  More use of the mailing list will make it possible for
meeting time to be focused on working out remaining, difficult issues.

Another factor is prioritization.  We want to allocate meeting time in
a way that will reap the most benefit.  Therefore higher priority work
items will be given enough time so that difficult issues can be
thoroughly worked through.

What does "higher priority" mean?  Here is a an idea of how priority
will be assigned:

  - Work items will receive meeting time in this order:

    - work items close to being finished that have been discussed
      thoroughly on the mailing list and for which there are remaining
      issues that cannot be resolved over mail.

    - work items under development that have been discussed at least
      some on the mailing list and for which at least some issues
      cannot be resolved over mail.

    - work items under development where proponents are having
      difficulty explaining concepts in mail, and for which
      presentation would help.

    - new work items not yet discussed on the mailing list

  - "Discussed on the mailing list" means discussion that takes place
    earlier than 2 weeks before the meeting, so we can put the agenda
    together and post it.  Clearly mailing list discussion can
    continue to and right through the meeting, but list discussion in
    the last 2 weeks before a meeting will not count in giving
    priority.

  - "Work items" includes items that other WGs or ADs want us to
    comment on, since those can and should be discussed on the mailing
    list first if possible.  In general when a chair says "we need
    your opinion asap", we should say "send it to the mailing
    list".  However, there can be things that come up at the last
    minute, so urgent insertions by ADs or other WG chairs are
    allowed.

Thoughts?

While we are developing this approach, don't delay using the list.
This approach will evolve over months, but starting right now we do
want to encourage working out issues on the mailing list and will
definitely be giving priority in the physical meetings to resolving
those issues that have already been discussed in mail but not worked
out.

Thanks ... Scott and Julien

---

From: "t.petch" <[email-masked]>
Date: Wed, 4 May 2011 12:10:04 +0200

----- Original Message -----
From: "Scott Brim" <[email-masked]>
To: "Internet Area" <[email-masked]>
Sent: Tuesday, May 03, 2011 1:17 AM

> thoroughly worked through.

Scott

My experience of other lists, which could well apply to Intarea, is
that many, if not most, lists would be more productive were the
chairs more active:-)

Drawing on that experience of other lists, what chairs might do more of is
 - chivy discussions when the list falls quiet
 - re-focus discussions when they wander off into other interesting realms
 - declare consensus when it is obvious that unanimity is not going to
be reached and do so before the list falls quiet from exhaustion or
frustration

Not rocket science, but at the same time, not followed as much as might be.
I like to be reminded that a chair is active at least once a week, preferrably
two or three times. And, implicitly if not explicitly, such interventions
prioritise.

I expect that a plot of mail list activity against time for most IETF WG
would show tri-annual modes, around the three meetings, which, to me,
is the great weakness of the IETF; we simply do not get on with things
and so take longer than we need to or should.

I have not been subscribed to Intarea for long so have yet to see if
any of this applies to Intarea, but suspect some of it might.

Tom Petch

> Thanks ... Scott and Julien

--------------------------------------------------------------------------------

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Scott Brim <[email-masked]>
Date: Wed, 4 May 2011 07:22:47 -0400

> be reached and do so before the list falls quiet from exhaustion or

Yup, absolutely.  I was going to do some chivying next week after seeing if
there were objections to the general principles. :-)

> and so take longer than we need to or should.

I fully agree.  I like to see work primarily done by mail, with f2f meetings
for unclogging stuck process.  If IntArea WG becomes more active we could
have an occasional teleconference to do the same.

Scott

---

From: Bob Hinden <[email-masked]>
Date: Wed, 4 May 2011 11:51:35 -0700

Scott,

> for the WG to be productive.  
........

> Thoughts?

I am generally supportive of this approach.  It's the approach all working groups should use.

My only concern is that I wonder if the int area w.g. should be careful to not take on big projects the end up excluding all else.  These might be better done in another working group (new or existing).  The reason I say this, is that one of the features of the Int Area w.g. is that new things can be brought for discussion for things that don't fit in an existing w.g.  Getting some time to present new ideas in a way that sometimes doesn't work on the mailing list.  If the w.g. has many work items, then there won't be much room for discussing new proposals.  This may be covered in your definition of "work items", but I thought it best to raise the issue.

Thanks,

Bob

---

From: Thomas Narten <[email-masked]>
Date: Wed, 04 May 2011 15:26:41 -0400

Hi Scott.

I'm generally supportive of your suggestions.

Some other thoughts:

Be more selective in what you give agenda time to. The idea that we
start with a slot and fill it up is the wrong way to do things. We
should look at what needs f2f time, and exclude everything else. Every
presentation should be prefaced with "can the community really afford
to spend time on this ID, or is it really just a distraction to real
work".

What I'd like to see:

- fewer presentations that are also given in other WGs. Int-area
  presentations should be for work that clearly is best pitched to
  int-area, after verifying that the work isn't appropriate elsewhere.

- No presentations for new material (i.e., work to take on) without
  there first being list discussion for the proposal AND there being
  some minimal level of support on the list that haveing a
  presentation is appropriate. Far too many folk are now in the mode
  of justifying attendance at meetings by writing a draft and giving
  presentations, when too often (IMO) the presentations waste the
  community's time.

- limit the number of presentations for non-WG documents. Give an ID
  one chance (maybe, but see the previous point), but if it's clear
  the document isn't gonna be adopted by the WG, don't keep giving
  them an agenda slot. Far too many WGs do that today.

- The default position for new work should be "no". It can't be enough
  that people aren't opposed or don't care. There needs to be real
  benefit to the work being done.

Thomas

---

From: Scott Brim <[email-masked]>
Date: Thu, 5 May 2011 08:28:37 -0400

> My only concern is that I wonder if the int area w.g. should be careful to not take on big projects the end up excluding all else.  These might be better done in another working group (new or exist…

Hi Bob.  Yes indeed.  A major charter item is to take care of
"proposals for the development and publication of RFCs that are not in
scope of an existing working group and do not justify the formation of
a new working group".  It's important that IntArea WG continue to
serve as an incubator.   However, we encourage discussion of these
items on the mailing list before the meeting.  The intent was that
these would fall under #2 and #3 of the prioritization list (work
items under development).  #1 (work items close to being finished)
doesn't have to be for big ticket items.

---

From: Scott Brim <[email-masked]>
Date: Thu, 5 May 2011 09:15:13 -0400

> to spend time on this ID, or is it really just a distraction to real

:-) yes

>  int-area, after verifying that the work isn't appropriate elsewhere.

I suspect that should depend on _why_ something is being presented in
multiple WGs.  If someone is forum-shopping that's not good and they
should figure out a venue with the various chairs.  If, after
consulting with chairs and ADs, work is seen as worthwhile but it's
not clear where it belongs, even which Area, then having it presented
multiple times feels like a good idea.  Where work belongs can be like
any other issue that isn't getting resolved by mail.  And of course,
in IntArea WG such presentations will get priority based on how
discussion goes on the mailing list.

>  presentation is appropriate.

Yes, but for items under #3 (proponents are having trouble
explaining), I would be more lenient -- the reason for presentation is
that the group cannot see yet whether there is value or not, so they
might not be supportive ... until after the presentation makes things
clear.

>  them an agenda slot. Far too many WGs do that today.

IntArea WG does act as an incubator.  Someone can bring a problem
statement and a solution approach, where the group might agree on the
problem but reject the solution -- in that case I would think they
could come again with revisions to their solution approach.  But the
big difference is adding more use of the mailing list.  The whole
process can and should be done primarily on the list, including
rejecting concepts.

>  benefit to the work being done.

Right.

Thanks ... Scott

---

From: Scott Brim <[email-masked]>
Date: Thu, 5 May 2011 09:33:44 -0400

Thomas: also on some of your points ...

>  benefit to the work being done.

These are taken care of in the WG Charter:

New work must satisfy the following conditions:

(1) WG consensus on the relevance for the Internet at large.

(2) WG consensus on the suitability and projected quality of the
proposed work item.

(3) A core group of WG participants with sufficient energy and
expertise to advance the work item according to the proposed
schedule.

(4) Commitment from the WG as a whole to provide sufficient
and timely review of the proposed work item.

(5) Agreement by the ADs, who, depending on the scope of the proposed
work item, may decide that an IESG review is needed first.

---

From: Scott Brim <[email-masked]>
Date: Thu, 5 May 2011 09:46:23 -0400

FYI I put this on the wiki at
<http://wiki.tools.ietf.org/wg/intarea/trac/wiki/MeetingTimePrioritization>

Scott

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 May 2011 10:40:16 -0400

On Thu, May 05, 2011 at 09:15:13AM -0400, Scott Brim wrote:

> multiple times feels like a good idea.

Having the same presentation multiple times is, in my opinion, not a
good idea, period.  If there really is a significant disagreement
about where a piece of work fits, then the chance that the same people
won't be in all the meetings where that discussion happens approaches
zero: only scheduling conflicts or actual uninterest make that
situation likely.  (I note in passing that often the "significant
disagreement about where a piece of work fits" is actually people
shopping for the friendliest crowd instead.  But we can't fix human
nature with process rules.)

I do think that intarea meetings are a good place to work out this
sort of disagreement.  All that is required, therefore, is a little
co-ordination in advance among the chairs of the various WGs when
there is this sort of "jurisdictional dispute".  The presentation in
most of the meetings is a two minute, "Here's the issue from this WG's
POV, go to intarea to resolve," and the discussion can then take place
in one location.  (The actual venue doesn't matter, and will probably
be dictated by who is last in the schedule that week.  The point is
that the same discussion doesn't need to happen in multiple places.)

And I heartily agree that much of this can be co-ordinated in advance
on lists.

> might not be supportive ... until after the presentation makes things

I actually think this sort of discussion -- i.e. less presentation and
more discussion -- is helpful.  IMO, these unbaked ideas can benefit a
lot from agenda time in "incubator" WGs like intarea, provided that
what one gets is a short presentation with a lot of time for
discussion and clarification.  15 minute slots with a 15 minute
presentation won't work for this: the author already understands the
idea as well as s/he can at the moment, because that's what's in the
draft.  I don't find elucidation in person usually helps in that case,
unless one can get up and say, "I have no clue what you mean in
section S," and the author has something to say then.

I'm aware that people are sometimes not comfortable talking in public
like that, or else are not easy enough in English to do this
comfortably.  It pains me to say this, but in that case I believe a
presentation is not going to help.  What such authors probably need is
direct help from one or two others first, and I don't believe that
solicitation in front of a crowd of 30 or more people is the way to
get that help.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Thu, 5 May 2011 13:19:33 -0700

Scott,

> doesn't have to be for big ticket items.

Thanks and I understand.

To put my comment another way, your proposal was for a fairly strict priority scheme.  New ideas will always have lower priority that exiting work items, so it may be hard to ever make it into the queue if there is a lot of existing work items.  There needs to be room in the procedures for the chairs and ADs to make some judgement calls.

Thanks,
Bob

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 May 2011 15:58:32 -0700

Hi Scott,
 
Sorry for the late reply. My talk on the Internet Routing
Overlay Network (IRON) was scheduled for a 15min timeslot
on the Intarea agenda for Prague, but it fell off the back
end of the schedule due to time constraints. The purpose
of the timeslot was to present architectural aspects of
IRON in order to inform the community of a new Internet
routing, addressing and mobility management architecture:

http://www.ietf.org/mail-archive/web/int-area/current/msg02642.html
http://www.ietf.org/mail-archive/web/int-area/current/msg02643.html

Due to the addition of IRON to the Intarea agenda, my
request to present its related functional elements (VET
and SEAL) during the Softwire wg meeting was denied:

http://www.ietf.org/mail-archive/web/softwires/current/msg01959.html

Hence, I lost out on both counts and the materials were
not presented in either forum.

While the IRON architecture has already been published as
RFC6179, I do not believe there is yet a sufficiently wide
understanding of the technology such that it would qualify
under your criterion of "items where proponents are having
difficulty explaining concepts in mail, and for which
presentation would help". So, it seems that we missed out
on an opportunity during the face-to-face meeting due to
the time constraints.

Moving forward from here, do you have any ideas on how
we can now begin to sensitize the community on IRON and
its related works given the lost face-to-face opportunity
in Prague?
 
Thanks - Fred
[email-masked]

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Brim
	Sent: Monday, May 02, 2011 4:18 PM
	To: Internet Area
	Subject: [Int-area] Steps to make the IntArea WG more productive

	Thoughts?

---

From: Scott Brim <[email-masked]>
Date: Fri, 27 May 2011 18:05:34 -0400

Hi Fred.  Sorry for being late.  I started the week with a 103.8F
(39.9C) fever.  That's all gone but I'm still moving slowly.

> While the IRON architecture has already been published as RFC6179, I
> do not believe there is yet a sufficiently wide understanding of the
> technology such that it would qualify under your criterion of "items
> where proponents are having difficulty explaining concepts in mail,
> and for which presentation would help".

If I understand correctly, you're saying there was discussion, but the
discussion didn't hit a wall, a failure of communication, and you didn't
have trouble explaining things.  What
happened?  Did it die out?  Did people believe they understood the
points, but you didn't believe?

I suggest that you list the points where you think there is
insufficient understanding, and we start there.

OK?

...Scott

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 May 2011 11:49:39 -0700

Hi Scott,

OK. I think there may be insufficient understanding on
the following points (and possibly others):

1) IRON is about managing tunnels between mobile clients
   and fixed servers. When the tunnel uses security, the
   system becomes one of managing mobile VPNs much in the
   same way as for MOBIKE:

    http://www.ietf.org/id/draft-templin-ironmike-01.txt

   IRON goes beyond the basic MOBIKE model to specify how
   the servers form a full/partial mesh between themselves
   so that clients can be tracked even if they move from
   server to server. Clients can be either a mobile router
   or a mobile host. An example use case is for mobile or
   nomadic devices connecting to a home enterprise network
   by locating a nearby VPN gateway, then changing to a new
   VPN gateway due to mobility events as necessary.

2) IRON is about suppressing routing scaling in the DFZ:

     http://www.rfc-editor.org/rfc/rfc6179.txt

   IRON networks advertise only highly-aggregated prefixes
   in the DFZ and delegate more-specific prefixes to IRON
   clients. The full/partial mesh of IRON servers provide
   the means for maintaining generally shortest path
   routing to mobile clients within the overlay network.

3) IRON is about route optimization:

     http://www.ietf.org/id/draft-templin-aero-00.txt

   When IRON client A wishes to connect to IRON client B,
   A first sends its initial packets through its own
   server S(A). S(A) then forwards the packets to B's
   server S(B). A is then redirected to S(B) so that
   subsequent packets do not need to flow through S(A).

4) IRON is about multiple interfaces. Consider an airplane
   that connects to the ground via multiple wireless links.
   IRON configures a mobile VPN over the multiple available
   links such that the VPN connection survives even if the
   underlying link states fluctuate.

5) IRON is a means for an ISP to provide overly network
   services to its client customers:

     http://www.ietf.org/id/draft-templin-iron-pm-01.txt

   A typical example would be for an ISP to delegate fully
   native IPv6 prefixes to client customers, then provide
   an overlay network routing system that connects clients
   to correspondents both within the ISP's overlay network
   as well as within the public Internet.

Again, this is a partial list but should be sufficient
to initiate discussion. What would you like to see in
terms of next steps?

Thanks - Fred

> -----Original Message-----
> From: Scott Brim [mailto:[email-masked]] 
> Sent: Friday, May 27, 2011 3:06 PM
> To: Templin, Fred L
> Cc: Internet Area
> Subject: Re: [Int-area] Steps to make the IntArea WG more productive
>

---

From: Scott Brim <[email-masked]>
Date: Tue, 31 May 2011 16:29:57 -0400

Fred: since you already have an RFC, what I am looking for is whether
there is a need for agenda time.  If nobody on this list -- where the
truly interested parties are to be found -- expresses disagreement or
confusion, then there is no reason to go over it again.

Could those who are interested in this topic please look at the points
below and respond by the end of the week, saying whether they have the
same understanding as Fred, or they disagree, or they need
clarification?  Please be as specific as possible.

... Scott