Subject: RFP for Remote Participation Services Specifications Development

From: IETF Administrative Director <[email-masked]>
Date: Wed, 19 Oct 2011 09:25:57 -0700 (PDT)

The IETF Administrative Oversight Committee (IAOC), on behalf of the IETF, announces this Request for Proposal
to develop the specifications for Remote Participation Services. The successful bidder will enter into a contract with
the Internet Society.

The primary goal of this project is to develop consensus on a set of requirements for IETF Remote Participation
Services (RPS) to enhance remote participation at IETF meetings, interim and virtual working group meetings.

Background
The IETF has supported remote meeting participation over the Internet for many years. For example, the audio of 
each session is made available in real time so that remote participants can listen to the proceedings. Instant messaging
is supported by having a jabber room 'conference' for each session, so that comments from remote participants can be 
relayed to people in the face-to-face meeting and to permit “side” exchanges that comment on material being 
presented. In addition, we have experimented with bi-directional audio support for remote presenters, as well as video 
broadcasting of the face-to-face meeting, but these more advanced features have, to date, have proved difficult to 
scale.

Environments
1. IETF Meeting Group Sessions
There are about 150 sessions, with up to 8 being simultaneous at any one time. A session varies in size from twenty to 
two hundred on-site participants.

2. IETF Meeting Plenary Sessions
There are two plenaries. On-site attendance at plenary sessions averages 700. The number of speakers at the front of
the room ranges up to twenty.

3. Interim Group Meetings
In addition to sessions during one of the three regular meetings, there can be as many as thirty Interim Working 
Group Meetings held throughout the world annually, serving a range of on-site participants from 15 to 50 and an 
unknown number of remote participants.

4. Virtual Group Meetings
There are currently 30-50 Virtual Group Meetings held throughout the year annually, serving 15-75 online 
participants from all parts of the globe. These have no physical, on-site instantiation and are conducted entirely
through teleconferencing tools.

The contractor is expected to highlight development and operational challenges to the functions that are defined. 

Deliverables

1. The IETF is seeking development of functional specifications for a suite of tools that enable Remote Participation
Services, meeting the needs described above, ideally enabling an experience for remote attendees that rivals that of 
on-site attendees.
2. The specifications shall rely solely upon IETF and other open standards for all communications and interactions.
3. At a minimum it is expected that the RPS will support the following real time functionality:
  a.  audio, bi-directional
  b.  video, bi-directional
  c.  instant messaging
  d.  slide presentations, including by remote attendees
  e.  whiteboard, for collaborative document development
  f.  conference control and moderation
  g.  transcription and broadcast of audio to text in real-time
  h.  ability to conduct and participate in straw polls.

In addition to real-time participation support, the service must support recording of an entire session, using 
standards-based encoding, to permit integration into the IETF meeting proceedings system.

Timeline

The contractor will observe group and plenary sessions at IETF 82 (Fall 2011 in Taipei) and conduct interviews with 
vendor teams (at a minimum, Meetecho, Adobe, Citrix and Webex when possible), the Network Operations Center
(NOC) volunteers, remote participants, and those individuals who run the working group and plenary sessions. After 
gathering all of this input, the contractor will prepare an initial specification for review by the IETF Tools Team and 
the vmeet mail list participants. Following these discussions, the contractor will update the specification as required.

Specifications will be circulated as IETF Internet-Drafts (I-D). It is expected that an initial I-D containing the 
specifications will be developed prior to IETF 83 (Spring 2012) and a completed I-D will be delivered prior to IETF 84 
( 2012).

The RFP can be found at: <http://iaoc.ietf.org/rfpsrfis.html>.

Proposals must be received via email at [email-masked] no later than November 1, 2011, 5:00 P.M. EDT. All 
questions/inquiries must be submitted in writing and must be received no later than midnight, EDT, October 24, 2011. 
Responses to questions and inquiries shall be posted on the IAOC website, <http://iaoc.ietf.org/rfpsrfis.html> by 
midnight, EDT, October 27, 2011.

The point of contact regarding this RFP is the IETF Administrative Director, Ray Pelletier.

Ray Pelletier
IETF Administrative Director

---

From: John C Klensin <[email-masked]>
Date: Thu, 20 Oct 2011 04:27:32 -0400

Ray and IAOC,

I hate to keep bringing this up, but the discussions leading up
to BCP 101 and the oft-replated principle of "maximum amount of
transparency to the IETF community that can be reasonably
obtained" strongly suggest that documents that are intended to
evolve into RFPs be circulated in draft to the IETF community
for comment.  If there is some reason why that it not possible,
reasonable transparency suggests that the IAD or IAOC
proactively provide an explanation to the community, rather than
waiting to be asked.   

Community review of draft RFPs is particularly important
because, for reasons outlined in BCP 101, there is little
opportunity for effective community input once proposals are
received and contract negotiations start.

Each time this issue has been raised in the past, the IAOC has
agreed that exposing RFP drafts is The Right Thing to do, yet
RFPs keep appearing without opportunity for community review.

Two omissions from this document illustrates why community input
is important:

(1) I don't know how much experience IAOC members have with
trying to participate remotely, but, having done so, there are
insights into what is needed that one just cannot obtain by
physically attending a meeting and observing how things work.
If any RFP or subsequent contract does not provide for input
from, and probably interviews of, selected people who have tried
to participate remotely while carrying out various roles, then
the odds are high that the resulting work will not be adequate
in practice.  Instead, this RFP appears to provide only for
"observ[ing] group and plenary sessions" and then review of the
initial specifications by groups that are unlikely to include
the full range of remote participants.  

It seems to me that a call for comments from those with actual
remote participation experience and for contractor interviews
with a selection of those people.   There is a long history of
asking developers and tool-builders what users need.  The
perceived success level in having a process that is limited to
asking developers and tool-builders produce results that
actually match user needs has been abysmal. 

(2) The list of "Environments" is also interesting.  Whether
caused by health issues, travel limitations, or other
considerations beyond the control of the individuals, we've had
experience that has required remote participation of IAB and
IESG members, members of key committees (the RSOC and RFC
Editorial Board are on my mind at the moment, but, if the IAOC
itself has not been affected yet, I believe that is only a
matter of time).  At least parts of the meetings of those groups
are, properly, not open.  While most of those meetings are
scheduled far in advance, ad hoc sessions for which
participation by members who happen to be remote do occur.
Those bodies and meetings create remote participation
requirements that are quite different from the environments
listed -- small meeting support that goes well beyond "8 being
simultaneous at any one time", a need for session privacy, and a
need to accommodate meetings that are scheduled on relatively
short notice.

I don't fault the IAD or IAOC for failure to identify those
types of issues internally.  I do believe it reinforces the
importance of getting community review of RFP drafts so that
there is maximum opportunity for others to spot issues that the
IAD and IAOC have overlooked.

In addition, while I don't believe members of the community
should be required to read and study IAOC minutes to find out
that particular RFPs are under development so that they can
comment, I note that no IAOC minutes have been posted since
those for an IAOC meeting held on 27 July during IETF 81.

I recommend that the RFP be withdrawn until modifications such
as those suggested above can be discussed by the IAOC and
further input on draft RFP provisions sought from the community.
I also recommend that no further RFPs be issued until the
relevant IAOC discussions and decisions be properly recorded in
IAOC minutes and those minutes posted.

    regards,
    john

--On Wednesday, October 19, 2011 09:25 -0700 IETF Administrative
Director <[email-masked]> wrote:

> The IETF Administrative Oversight Committee (IAOC), on behalf
> of the IETF, announces this Request for Proposal to develop
> the specifications for Remote Participation Services. The
> successful bidder will enter into a contract with the Internet
> Society.
> 
> The primary goal of this project is to develop consensus on a
> set of requirements for IETF Remote Participation Services
> (RPS) to enhance remote participation at IETF meetings,
> interim and virtual working group meetings.
> 
> Background
> The IETF has supported remote meeting participation over the
> Internet for many years. For example, the audio of  each
> session is made available in real time so that remote
> participants can listen to the proceedings. Instant messaging
> is supported by having a jabber room 'conference' for each
> session, so that comments from remote participants can be 
> relayed to people in the face-to-face meeting and to permit
> side exchanges that comment on material being  presented. In
> addition, we have experimented with bi-directional audio
> support for remote presenters, as well as video  broadcasting
> of the face-to-face meeting, but these more advanced features
> have, to date, have proved difficult to  scale.
> 
> Environments
> There are about 150 sessions, with up to 8 being simultaneous
> at any one time. A session varies in size from twenty to  two
> hundred on-site participants.
> 
> There are two plenaries. On-site attendance at plenary
> sessions averages 700. The number of speakers at the front of
> In addition to sessions during one of the three regular
> meetings, there can be as many as thirty Interim Working 
> Group Meetings held throughout the world annually, serving a
> range of on-site participants from 15 to 50 and an  unknown
> number of remote participants.
> 
> There are currently 30-50 Virtual Group Meetings held
> throughout the year annually, serving 15-75 online 
> participants from all parts of the globe. These have no
> physical, on-site instantiation and are conducted entirely
> The contractor is expected to highlight development and
> operational challenges to the functions that are defined. 
> 
> Deliverables
> 
> 1. The IETF is seeking development of functional
> specifications for a suite of tools that enable Remote
> Participation Services, meeting the needs described above,
> ideally enabling an experience for remote attendees that
> rivals that of  on-site attendees.
> 2. The specifications shall rely solely upon IETF and other
> open standards for all communications and interactions. 3. At
> a minimum it is expected that the RPS will support the
> following real time functionality:   a.  audio, bi-directional
>   b.  video, bi-directional
>   c.  instant messaging
> In addition to real-time participation support, the service
> must support recording of an entire session, using 
> The contractor will observe group and plenary sessions at IETF
> 82 (Fall 2011 in Taipei) and conduct interviews with  vendor
> teams (at a minimum, Meetecho, Adobe, Citrix and Webex when
> possible), the Network Operations Center (NOC) volunteers,
> remote participants, and those individuals who run the working
> group and plenary sessions. After  gathering all of this
> input, the contractor will prepare an initial specification
> for review by the IETF Tools Team and  the vmeet mail list
> participants. Following these discussions, the contractor will
> update the specification as required.
> 
> Specifications will be circulated as IETF Internet-Drafts
> (I-D). It is expected that an initial I-D containing the 
> specifications will be developed prior to IETF 83 (Spring
> 2012) and a completed I-D will be delivered prior to IETF 84 
> ( 2012).
> 
> Proposals must be received via email at [email-masked] no
> later than November 1, 2011, 5:00 P.M. EDT. All 
> questions/inquiries must be submitted in writing and must be
> received no later than midnight, EDT, October 24, 2011. 
> Responses to questions and inquiries shall be posted on the
> IAOC website, <http://iaoc.ietf.org/rfpsrfis.html> by

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 20 Oct 2011 11:49:58 +0200

On 20 October 2011 10:27, John C Klensin wrote:

[...}

+1

Two "it's only me" observations:  What some mobile
broadband providers euphemistically sell as "ISDN"-
speed in Germany and what Microsoft claims to be a
"media player" is a major PIT* with whatever the
IETF considers as "audio streaming".

If there are good jabber scribes not assuming that
"audio" remotely works or is related to their side
of "real time" remote jabber participation can be
fun.  Even if jabber doesn't work very well there
are often at least interesting jabber logs.

-Frank

---

From: John C Klensin <[email-masked]>
Date: Thu, 20 Oct 2011 06:02:09 -0400

> are often at least interesting jabber logs.

And the time-lag differences among the IETF audio stream, other
audio arrangements (WebEx, Skype, etc.), and the jabber activity
can be seriously crazy-making.  I didn't intend my examples to
be comprehensive, only to illustrate that it is important to
talk with users.   Thanks, Frank, for adding to the list.

   john

---

From: "George, Wes" <[email-masked]>
Date: Thu, 20 Oct 2011 08:41:12 -0400

I'm also completely mystified as to why IPv6 support for all proposed/requested features is not an explicitly stated requirement, even at this phase. It's not always as simple as "we'll make sure we make it IPv6 capable when we implement it..." with the sorts of solutions you're looking for here. Knowing that we require this at this phase would allow for some vendor self-selection or proper time to fix the gaps prior to formal proposals, so that we don't end up with lip service around IPv6 support.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 20 Oct 2011 09:33:43 -0400

On 2011-10-20 08:41, George, Wes wrote:
> I'm also completely mystified as to why IPv6 support for all
> proposed/requested features is not an explicitly stated requirement,
> even at this phase.

And more generally, this should be considered an opportunity for
dogfooding the protocols we create. IPv6 is one of them. SIP, RTP, the
XCON stuff, and XMPP could be others.

It would be very sad if we end up with the usual everything-over-HTTP
Flash applet stuff.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 20 Oct 2011 07:06:34 -0700

> IETF considers as "audio streaming".

icecast http/mp3 streaming is as commonly supported as anything I could
find. on balance the majority of internet radio runs over it and there
are both generic as well as specialized clients for virtually every
modern platform.

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

---

From: Dave Cridland <[email-masked]>
Date: Thu, 20 Oct 2011 15:07:59 +0100

> XCON stuff, and XMPP could be others.
Right - the current system is XEP-0045 (an XSF thing) over XMPP (an  
IETF thing), supplemented by MP3 over HTTP for audio. The chatrooms I  
find fine - if anyone has suggestions for what else those need to do  
I'd appreciate knowing (as would the rest of the participants in the  
standards group at the XSF).

Having audio fed over RTP would be an obvious first step, and that  
could be negotiable by both XMPP and SIP clients.

As a remote participant for the vast majority of IETFs I've (not?)  
attended, I'd humbly suggest that the most useful things a remote  
participant can have are reasonably synchronized audio (instead of  
several seconds delay, which makes timely responses difficult) and  
ensuring that the chatrooms are visible in the physical room (thus  
making all in-room participants aware of the chatroom's remote  
participants and what their input is). A second projector and screen  
in the room is embarrassingly low-tech, but very effective.

I can see the utility of having some kind of screencast thing for the  
slides, although as a rule, I hate slides, so this comes a distant  
third. Being able to downlaod them and sing along at home is just  
fine.

I don't particularly care if my actual voice isn't heard in the room.  
I understand that many will miss my dulcet tones, of course, but the  
thing I really want to be able to do, as a remote participant, is  
participate.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: SM <[email-masked]>
Date: Thu, 20 Oct 2011 03:29:46 -0700

>trying to participate remotely, but, having done so, there are

I'll rephrase that as "I don't know how much experience IAOC members 
have with trying to participate in a working group remotely".  I hope 
that is clear in case an IAOC member would like to comment.

>the full range of remote participants.

If the experience is based on usage of Meetecho, Adobe, Citrix and 
Webex, it does not cover my use case.  These services may be good 
enough for some use cases but they have enough failure modes to make 
remote participation difficult.  The RFP mentions bidirectional audio 
and video.  As John has attempted to chair a working group remotely, 
he might be aware that real-time can mean more than 10 seconds 
between the time an event occurs and when it is registered at the remote end.

>those for an IAOC meeting held on 27 July during IETF 81.

I noticed that too.

>IAOC minutes and those minutes posted.

I doubt that's going to happen.

I would be grateful if Meetecho, Adobe, Citrix and Webex could be 
kept as experimental instead of being standardized.  XMPP works 
fine.  The current audio feed may not be sexy but it actually works 
in less than ideal environments.  BTW, the audio feed for the plenary 
sessions could be published on the agenda web page as it is usually a 
hassle to find.

Regards,
-sm

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 20 Oct 2011 17:15:26 +0200

John and others.

On 20/10/2011 10:27, John C Klensin wrote:

> I hate to keep bringing this up, 
[...]
> further input on draft RFP provisions sought from the community.

-1.

Or I disagree completely here and I do not see the need for the RFP to
be withdrawn.

The task is clear, it is to write an ID with the requirements.  The
ID process offers sufficient opportunities for the community to
provide input, it is a matter of finding somebody to hold the pen
and write the document.   I think we should move forward here and
start doing the work, not endlessly discuss the fine details of a
process.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk(at)uijterwaal.nl
                                          http://www.uijterwaal.nl
                                          Phone: +31.6.55861746
------------------------------------------------------------------------------

There appears to have been a collective retreat from reality that day.
                                 (John Glanfield, on an engineering project)

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 20 Oct 2011 12:02:08 -0400

> From: IETF Administrative Director [[email-masked]]
> Sent: Wednesday, October 19, 2011 12:25 PM
> 
> The IETF Administrative Oversight Committee (IAOC), on behalf of the
> IETF, announces this Request for Proposal to develop the
> specifications for Remote Participation Services. The successful
> bidder will enter into a contract with the Internet Society.
> [...]

Actually the RFP is at
http://iaoc.ietf.org/documents/RPS-Specifications-RFP-2011-10-19.pdf

Yes, it's a PDF file, not a standardized format!  Talk about not
eating our own dogfood!

> Proposals must be received via email at [email-masked] no later
> than November 1, 2011, 5:00 P.M. EDT.

13 days for the vendors to become aware of the proposal and answer it?
That sounds unlikely to get optimal participation.  (Unless the IAOC
has already been working with prospective vendors.)

Dale

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 20 Oct 2011 18:04:06 +0200

Hi,

you might want to have a look at the Meetecho IETF sites (see, e.g., http://ietf81.conf.meetecho.com/), which contain session recordings and give you a flavour of what is currently available to remote participants. BTW, Meetecho is XCON, mediactrl, RTP and XMPP compliant. As far as I saw, most of the desiderata included in the RFP message might be satisfied with our platform, which, not by chance, has been conceived at the outset with an IETF-minded approach.

Simon

Dave Cridland <[email-masked]> ha scritto:

Dave.
_____________________________________________

Ietf mailing list
[email-masked]

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 20 Oct 2011 17:40:22 +0200

Hi,

Simon

Dave.

Ietf mailing list
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 Oct 2011 09:29:06 -0700

i read the message from ray as an rfp for someone to write the rfp for
remote services.  aside from being a very amusing bureaucratic layer
cake, this would not seem to need a lot of experience with remote
access, but rather good ears and a taste for the bureaucracy and discord
the ietf has become.

randy

---

From: SM <[email-masked]>
Date: Thu, 20 Oct 2011 09:40:25 -0700

>Or I disagree completely here and I do not see the need for the RFP to

There could at least be a modicum of transparency.

>start doing the work, not endlessly discuss the fine details of a

Breaking stuff that works does not qualify as an endless discussion 
of the fine details of a process in my book.

The RFP will cost money.  In theory, such decision have to be 
documented, justified and there should be community review.  The IAOC 
did not publish any details about Valley View.

At 09:04 20-10-2011, Simon Pietro Romano wrote:
>you might want to have a look at the Meetecho IETF sites (see, e.g., 
><http://ietf81.conf.meetecho.com>http://ietf81.conf.meetecho.com/), 
>which contain session recordings and give you a flavour of what is 
>currently available to remote participants. BTW, Meetecho is XCON, 
>mediactrl, RTP and XMPP compliant. As far as I saw, most of the 
>desiderata included in the RFP message might be satisfied with our 
>platform, which, not by chance, has been conceived at the outset 
>with an IETF-minded approach.

It's all nice to pick a solution that is based on protocols developed 
within the IETF.   In the wild, you can expect sign-up that doesn't 
work.  You'll find participants having to hunt down the audio stream 
as that information is not published.  The server is hosted in 
Italy.  If I recall correctly, there were some connectivity 
issues.  This is not about Meetecho not offering a good service.  I 
am aware that you responded to the questions to get things working.

draft-jaeggli-ietf-streaming-media-status-00 discussed about IETF 
streaming.  As Meetecho has been around since a few meetings, it 
would be helpful to have some documentation about the experience gained.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Thu, 20 Oct 2011 13:40:11 -0400

--On Thursday, October 20, 2011 17:15 +0200 Henk Uijterwaal
<[email-masked]> wrote:

> Or I disagree completely here and I do not see the need for
> the RFP to be withdrawn.
> 
> The task is clear, it is to write an ID with the requirements.
> The ID process offers sufficient opportunities for the
> community to provide input, it is a matter of finding somebody
> to hold the pen and write the document.   I think we should
> move forward here and start doing the work, not endlessly
> discuss the fine details of a process.

Henk,

Actually, unless the IAOC has already selected either a vendor
or a short list of vendors, that isn't the task.  The task is to
get proposals from a selection of vendors and then pick on.  In
that regard, the list of issues the proposing contractor is
supposed to consider ("the Environment") is very important
because some potential proposers might, at least in principle,
submit a proposal for some list of environments to be supported
but not feel they were competent to evaluate others.   If the
community introduces completely new issues or environments to be
considered once we go into the I-D process, a contractor might
be entirely justified to say either "not in the contract and I'm
not going to do it because I can't do it well" or "not in the
contract, it will cost you $XYZ extra for me to write
requirements for it, please send money".  Neither is a desirable
situation, to put it mildly.

With regard to transparency and openness to community input, I
suggest that exposing a draft RFP to community review
--something the community has asked for several times and which
the IAOC has generally agreed is reasonable and appropriate--
serves two separate purposes.  You can dismiss the second as
"fine details of a process", but it seems to me that the first
is quite substantive.

(1) The IETF Community often has perspectives on issues that are
broader from those represented on the IAOC.  Consequently,
community input may actually provide ideas that should be
discussed and evaluated as to whether they should be in the RFP
(remembering that a different set of tasks may yield different
bidders).  The few hours of discussion since I sent my note
illustrate the issues: whether you believe that consideration
for IPv6, poor-connectivity participant environments, more
specific consideration of input from those who have experienced
remote participation in various roles, or remote participation
in non-WG/non-BOF meetings is important, those issues should at
least be aired and discussed, openly, by the IAOC.  Perhaps
they, and whatever else might be identified, already have been
discussed and the IAOC has made decisions about them that the
community will find acceptable.  But, if they have, there is no
way to find out from any minutes that have been published, which
is why that isn't a "fine detail of process" either.

(2) The IAOC is required to be open and transparent with the
IETF community, including publishing timely minutes.  Maybe no
one cares any more or maybe the IAOC has concluded that the
expectation/ requirements are impossible.  But then another
provision of BCP 101 applies, which is that the IAOC, having
noticed that some procedures cannot be followed or requirements
met, is obligated to identify the problem to the community and
recommend changes to solve it.   I don't consider simply
ignoring those rules to be an option or even a fine detail of
process, but YMMD.

best,
   john

---

From: Bob Hinden <[email-masked]>
Date: Thu, 20 Oct 2011 10:50:46 -0700

John,

The RFP is not a solicitation to vendors of remote participation services.  It is to hire someone to write a requirements document for remote participation services.  It is not to develop any code nor are the items listed in the RFP the only things that should be included.  Note that it explicitly calls for having community input into the requirements.  The RFP includes:

  "After gathering all of this input, the contractor will prepare an
   initial specification for review by the IETF Tools Team and the
   vmeet mail list participants."

and

  "Specifications will be circulated as IETF Internet-Drafts (I-D)"

The intent of this work is to develop a set of requirements for community review.  I don't see any significant value in asking the community for input on an RFP that is for hiring someone to write a specification to generate community input.  

Also, while the SOW does not indicate it, because it is not something the contractor will do, the Internet-Draft will be "last called" to confirm that it represents community consensus.  This will be done by the General AD as has been done earlier with other specification tasks.

Regarding the IAOC minutes, the IAOC is aware that there is a problem.  I am sorry to report that the current volunteer approach to taking and producing IAOC minutes is not working.  I had hoped we could make the volunteer approach work.  The IAOC concluded on today's IAOC call that we should approach ISOC to get additional administrative support to improve this function.  I will report on the outcome of that in Taipei.

Regards,
Bob

On Oct 20, 2011, at 1:27 AM, John C Klensin wrote:

> IAOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iaoc

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 Oct 2011 11:09:19 -0700

> I don't see any significant value in asking the community for input on
> an RFP that is for hiring someone to write a specification to generate
> community input.

the problem may be that you may lack a sense of humor, an appreciation
of recursion, and a vision for just how twisted ietf process can be
made.

can we please restart the poisson wg so all this can be moved elsewhere?

randy

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 20 Oct 2011 15:15:57 -0400

> From: Simon Perreault [[email-masked]]
> 

I agree with the sentiment, but at *this* stage, that is, *finding*
someone to write the requirements, the RFP should not include specific
requirements for the remote participation system.

Dale

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 20 Oct 2011 15:21:57 -0400

One thing to consider is charging for this service

I have no problem paying some fee to the IETF in order to get better remote
participation capability when I am unable to travel to the location chosen.

I would much rather pay $200-$300 to have good remote attendance capability
(video etc.) than get by on 'free'.

This would be assuming that there would be some markup on the remote
attendance cost to finance the secretariat etc.

This is not something I would have suggested until recently because the
broadband connectivity has not been up to it until very recently.

-- 
Website: http://hallambaker.com/

---

From: John C Klensin <[email-masked]>
Date: Thu, 20 Oct 2011 15:23:24 -0400

--On Thursday, October 20, 2011 10:50 -0700 Bob Hinden
<[email-masked]> wrote:

> John,
> 
> The RFP is not a solicitation to vendors of remote
> participation services.  It is to hire someone to write a
> requirements document for remote participation services.  It
> is not to develop any code nor are the items listed in the RFP
> the only things that should be included.  

Bob,

I was somewhat confused by differences between the description
of the RFP in the announcement that was sent out and the RFP
itself (aggravated very slightly by the link in the announcement
not being correct).  I apologize for that confusion at the same
time I suggest that propriety suggests that they should be
consistent.

That said, I understood that this was to hire someone to write a
requirements document.  I suggest that, if you want a fair and
open process, it would be good to follow the rules closely
enough to make it possible for non-insiders to bid (or to make
it explicit that only insiders and regular attendees are
eligible).

As I mentioned in my response to Henk, what you ask for in an
RFP not only affects what you get (even if all you are looking
for is a requirements spec) and who is likely to consider it
plausible to bid.  More important, I see nothing in BCP 101 that
says that the IAOC does not need to expose draft RFPs to
community review just because they do not, e.g., require code to
be written.  If the IAOC believes that such an exception is
needed because things don't work without it, then BCP 101 very
explicitly requires that the IAOC submit a change proposal to
the community.  That hasn't been done, so there is no exception.

> Note that it
> explicitly calls for having community input into the
> requirements.  The RFP includes:
> 
>   "After gathering all of this input, the contractor will
> prepare an    initial specification for review by the IETF
> Tools Team and the    vmeet mail list participants."
> 
> and
> 

Right.  But those are provisions for community review of a
requirements spec, expressed as an I-D.  We know how to handle
those, especially if you already have General AD and IESG
agreement for a Last Call.  What I'm concerned about is
community review of the RFP to be sure that any proposals
address the right set of issues and use adequate mechanisms to
be sure a good spec is developed (see my note to Henk).

> The intent of this work is to develop a set of requirements
> for community review.  I don't see any significant value in
> asking the community for input on an RFP that is for hiring
> someone to write a specification to generate community input.  

Again, I don't believe that BCP 101 or the associated
discussions and precedents give you (or the IAOC) the authority
to eliminate community review on the grounds that you don't see
it as having significant value.  Consider what would happen if
the IESG decided to waive IETF Last Call on a Standards-Track
document on the grounds that they understood the community well
enough to know that such a Last Call would be unlikely to yield
any significant comments.   I have no doubt that they could make
those judgments and make them accurately, but that is not the
point.  Nor is the IAOC authorized to translate its obligations
about transparency and openness to community comment so that it
applies only in cases where you believe there is significant
value in asking.

>...
> Regarding the IAOC minutes, the IAOC is aware that there is a
> problem.  I am sorry to report that the current volunteer
> approach to taking and producing IAOC minutes is not working.
> I had hoped we could make the volunteer approach work.  The
> IAOC concluded on today's IAOC call that we should approach
> ISOC to get additional administrative support to improve this
> function.  I will report on the outcome of that in Taipei.

I look forward to your report, but have a sense of deja vu about
prior discussions of this problem and similar commitments.
Perhaps I was just dreaming on the prior occasions.

best,
   john

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 20 Oct 2011 14:29:35 -0500

On 10/20/2011 02:21 PM, Phillip Hallam-Baker wrote:
> I have no problem paying some fee to the IETF in order to get better
> remote participation capability when I am unable to travel to the
> location chosen.
>
> I would much rather pay $200-$300 to have good remote attendance
> capability (video etc.) than get by on 'free'.

I would also be onboard with paying a reasonable (USD200) fee to have 
high-quality remote participation available. The free options should 
still exist, but they can continue to be 'best-effort' services.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: John C Klensin <[email-masked]>
Date: Thu, 20 Oct 2011 15:41:22 -0400

--On Thursday, October 20, 2011 15:21 -0400 Phillip Hallam-Baker
<[email-masked]> wrote:

> I have no problem paying some fee to the IETF in order to get
> better remote participation capability when I am unable to
> travel to the location chosen.
> 
> I would much rather pay $200-$300 to have good remote
> attendance capability (video etc.) than get by on 'free'.
>...

Hi.

As others have pointed out, this is an RFP about writing a
requirements spec.  Please examine the announcement and RFP (I
assume the latter is authoritative, but am not sure) to
determine whether you think the RFP should require that a
contractor include studying this issue as part of the task.
Perhaps it is.  If so, you should be objecting to the RFP
itself.  If not, this type of comment should probably be raised
when the first draft I-D shows up.

IMO, the question of "environments" to be examined is definitely
insufficient in the RFP, not because it prohibits a contractor
from doing or proposing anything else (as Bob points out, it
doesn't) but because I believe a draft requirements
specification would be completely inadequate unless some or all
of those issues -- especially issues with meetings that do not
conform to the paragraph starting "Each session..." in the
"Background" part of the SOW in the RFP --  were addressed.

Similarly, I don't think the RFP is adequate unless it insists
on proposals in which applicants provide details about their
plans for "conducting interviews" with the various listed
parties.  Some of those groups, especially those who have
actually participated remotely in one or more meetings but
normally attend in person and those who almost always
participate remotely, are often underrepresented in IETF
considerations and easily blown off, especially if the
contractor expects all interviews to be completed in the IETF 82
timeframe.   Without such a requirement, we could easily find
ourselves in a situation in which a contractor said "we bid on
the basis of resources to conduct interviews that week; if
additional interviews are needed, you will need to adjust the
terms".

I cite those as examples of comments on the RFP in the hope of
making the distinction between such comments and an attempt to
pre-discuss the I-D that will presumably come out of this
process.

best,
   john

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 Oct 2011 13:08:06 -0700

> One thing to consider is charging for this service

i strongly agree.  whoever is drafting the rfp should charge heavily for
putting up with massive micromanagement.

---

From: [email-masked]
Date: Thu, 20 Oct 2011 21:48:02 +0000

Requirements are one thing.

How about some discussion of "goals" to drive the requirements?  For example, is it a goal of the RFP to specify a tool set that would be so good that people would pay to use it?  

My reaction to the text in the announcement of the RFP is that the overall objectives are ill-defined.

> to enhance remote participation at IETF meetings,

What does "to enhance" mean in this context?

If I was at all interested in bidding on this new piece of spec development work, I would either ask for a lot more clarity on the desired goals of "enhanced" remote participation, or I would propose that the first phase of the project should be focused on developing some consensus on this.

+1 to John Klensin's view that if the RFP had been reviewed by the community before publication, it would have been better.

Regards,

Ed  J.

-----Original Message-----
From: John C Klensin <[email-masked]>
Sender: [email-masked]
Date: Thu, 20 Oct 2011 15:41:22 
To: Phillip Hallam-Baker<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Subject: Re: Anotherj RFP without IETF community input (was: Re:
	RFP for Remote Participation Services Specifications Development)

Hi.

best,
   john

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 21 Oct 2011 12:03:55 +0100

John,

On 10/20/2011 8:23 PM, John C Klensin wrote:
> More important, I see nothing in BCP 101 that
> be written.

Please forgive my limited reading comprehension, but I could not find any 
reference to RFPs in BCP 101 at all.  More broadly, I could not find any details 
that specify what /is/ or is /not/ required to be cycled through community 
review and approval or when.

The implication of your above statement appears to be that there is a 
requirement for explicit BCP 101 permission /not/ to get community review and 
that, absent that, there is a default requirement that /all/ decision-making by 
the IAOC must have community review and approval, prior to the decision-making. 
  Since that is patently impractical, I suspect you do not intend that requirement.

And therein lies the core difficulty with your original note and the similar 
ones before it:  You appear to have a private version of highly detailed 
specification for IAOC policies and procedures and are holding the IAOC 
accountable for following it.  What you claim as natural, obvious and exclusive 
interpretations of BCP 101 are actually subject to highly variable -- and 
equally reasonable -- alternatives.  Hence, neither the IAOC nor the rest of the 
community can accurately predict what is in your private specification.

As the new guy on the IAOC block, I am trying quite hard to understand how 
things are done and, as usual, often wonder how they might be done differently. 
  So far, I've seen the IAOC pay quite a bit of attention to /practical/ 
transparency.  That is, balancing that goal with the pragmatics of getting work 
done, especially amongst a collection a volunteers.

The consistent certitude underlying the tone of your criticisms suggests 
strongly that you hold very different details for assessing the IAOC than are 
visible to the rest of us.

It would therefore be extremely helpful for you to thoroughly document those 
details and then to obtain IETF consensus for them.

Perhaps that could even result in your no longer having to post criticisms that 
are so painful for you.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Bob Hinden <[email-masked]>
Date: Fri, 21 Oct 2011 06:30:58 -0700

John,

You seem to be making a lot of assumptions about the RFP that aren't part of the RFP.  Or perhaps you are reading between the lines.  For example that the RFP will only be sent to the IETF list, that we won't allow non-IETFers to bid, that no discussion will occur between who ever does this work and the community, that the requirements are fixed, that the conclusions are pre-determined, etc., etc.  

The goal of the RFP is to hire someone who will investigate the problem, talk to many people, analyze the data, and make a proposal for what is doable.  The RFP is not a specification of the outcome.  We want to hire someone who will think about the problem space and make a proposal for the functions that should be present in a remote access system that the IETF will use.   Any contract awarded based on this RFP will require the contractor to interact with the community.  

BCP101 requires the IAOC to operate in a transparent manner.  I don't see how publishing an RFP to hire someone to write a specification that includes public review of the work and an IETF wide last call isn't transparent.  It would have been non-transparent if the IAOC had hired someone with out first doing a public RFP.  BCP101 doesn't require that everything the IAOC thinks about must be first sent to the community for review.  

Bob

---

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 21 Oct 2011 16:54:56 +0200

Dear sm,

just for the sake of completeness, I have to say that the following 
statement is not 100% correct:

>
>  The RFP mentions bidirectional audio and video.  As John has 
> attempted to chair a working group remotely, he might be aware that 
> real-time can mean more than 10 seconds between the time an event 
> occurs and when it is registered at the remote end.

I am quite confident that none of the tools you mention entails such a 
long delay. You are probably talking about the mp3 audio feed, which, as 
far as I know, has never been meant to represent a real-time, 
bidirectional means of interaction (and which, btw, proves really 
helpful when you want to access high-quality recordings after the meeting).
I can state for sure that we have used Meetecho for remote presentations 
in Hiroshima, in the mediactrl WG meeting: interaction happens in 
real-time.

Cheers,

Simon

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Eric Burger <[email-masked]>
Date: Fri, 21 Oct 2011 15:15:51 +0000

Simon - Careful what you promse. I am sure someone will try to use the service through two satelite hops and then complain about the latency. Unfortunately, we cannot (yet) get of this speed of light thing :-)

On Oct 21, 2011, at 2:54 PM, Simon Pietro Romano wrote:

> Dear sm,
> 
> just for the sake of completeness, I have to say that the following statement is not 100% correct:
> 
>> 
>> The RFP mentions bidirectional audio and video.  As John has attempted to chair a working group remotely, he might be aware that real-time can mean more than 10 seconds between the time an event occurs and when it is registered at the remote end.
> 
> I am quite confident that none of the tools you mention entails such a long delay. You are probably talking about the mp3 audio feed, which, as far as I know, has never been meant to represent a real-time, bidirectional means of interaction (and which, btw, proves really helpful when you want to access high-quality recordings after the meeting).
> I can state for sure that we have used Meetecho for remote presentations in Hiroshima, in the mediactrl WG meeting: interaction happens in real-time.
> 
> Cheers,
> 
> Simon
> 
> -- 
>                            _\\|//_
>                            ( O-O )

---

From: Acee Lindem <[email-masked]>
Date: Thu, 20 Oct 2011 16:02:13 -0400

On Oct 20, 2011, at 3:21 PM, Phillip Hallam-Baker wrote:

I have no problem paying some fee to the IETF in order to get better remote participation capability when I am unable to travel to the location chosen.

I would much rather pay $200-$300 to have good remote attendance capability (video etc.) than get by on 'free'.

This would be assuming that there would be some markup on the remote attendance cost to finance the secretariat etc.

I disagree. If the remote participation service is high quality, it should require the same registration fee structure as on-site participation.

Thanks,
Acee

This is not something I would have suggested until recently because the broadband connectivity has not been up to it until very recently.

On Thu, Oct 20, 2011 at 12:29 PM, Randy Bush <[email-masked]<mailto:[email-masked]>> wrote:

randy

---

From: SM <[email-masked]>
Date: Thu, 20 Oct 2011 15:17:54 -0700

Hi Bob,
At 10:50 20-10-2011, Bob Hinden wrote:
>The intent of this work is to develop a set of requirements for 
>community review.  I don't see any significant value in asking the 
>community for input on an RFP that is for

I would be concerned if a Chair skipped the community step on the 
presumption that it will not be of significant value.  There has been 
previous discussions about individuals using the IETF affiliations 
without IESG, IAB or WG approval.  These individuals might not have 
seen any significant value in notifying the relevant body.

Regards,
-sm

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 21 Oct 2011 10:55:28 -0500

> I disagree. If the remote participation service is high quality, it should require the same registration fee structure as on-site participation.

Why? Presumably a significant portion of the registration fee goes to 
pay the venue for use of its space, for food and beverages, and other 
costs that remote participants don't incur.

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 21 Oct 2011 12:03:29 -0400

On Fri, Oct 21, 2011 at 11:55 AM, Kevin P. Fleming <[email-masked]> wrote:
>> remote participation capability when I am unable to travel to the location
>> chosen.
>>
>> I disagree. If the remote participation service is high quality, it should
>> require the same registration fee structure as on-site participation.
>
> Why? Presumably a significant portion of the registration fee goes to pay
> the venue for use of its space, for food and beverages, and other costs that
> remote participants don't incur.
>

I think it is fair to say that the costs will clearly be _different_.
Remote participants won't get cookies,
but might require technical support, for example. I think it is too
early to say how that
should be reflected in charging for a premium service.

Regards
Marshall

---

From: Melinda Shore <[email-masked]>
Date: Fri, 21 Oct 2011 10:58:33 -0800

On 10/20/2011 12:02 PM, Acee Lindem wrote:
> I disagree. If the remote participation service is high quality,
 > it should require the same registration fee structure as on-site
 > participation.

It seems to me that any fees (and I've got some issues with that:
see below) should be tied to the expense of providing the service.

But aside from that it seems to me that there's historically been
an interest in keeping IETF processes open.  I don't think we want
to get into a situation in which only people whose participation
costs are covered by an employer or someone's got enough money to
fund themselves.  I don't think that this would be particularly an
issue if meetings haven't increasingly become the place where
decisions are made (sorry, it does happen far too often) and centers
of working group activity.  It's increasingly the case that if you
want to do work at the IETF, you need to go to meetings.  I'd have
considerable reservations about asking for the kind of money you're
suggesting.

But first, let's find out what it actually would actually cost
the IETF.

Melinda

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 22 Oct 2011 10:51:04 +0100

> (video etc.) than get by on 'free'.

my ietf participation budget is zero.  If remote attendance is pay-walled,
people with zero budget will drop off the air.

Nick

---

From: Eric Burger <[email-masked]>
Date: Sat, 22 Oct 2011 10:30:07 +0000

+1

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 23 Oct 2011 07:26:35 +0100

On 10/21/2011 7:58 PM, Melinda Shore wrote:
>  It's increasingly the case that if you

Melinda,

I've changed the subject line because the point you raise is orthogonal to the 
main thread, but since you raise it, it's worth exploring a bit (since I happen 
to agree with your observation.)

The dynamics that make this true seem to have to do with changes in our 
community rather than in the nature of the technical work or the online tools.

So the question is how to move the center of gravity back to mailing lists?

d/

-- 

   Dave Crocker

---

From: Eric Burger <[email-masked]>
Date: Sun, 23 Oct 2011 11:50:07 +0000

It gets worse.  To attend every IETF meeting costs about $10,000 per year.  If we say one has to go to the face-to-face meetings, we limit the IETF to participants from corporations or entities that will sponsor the individual (pay to play?), IETF participants that have independent funds, or people that can generate significantly more than $10,000 per year from their IETF activities.  $10,000 per year is not within a typical individual's budget.  This is more especially so if the individual comes from a region of the world where the per-capita GDP is below $10,000 per year.

Where does the $10,000 figure come from? It is based on the following assumptions:
One trip is far, so $2,000 for airfare
One trip is near, so $400 for airfare
One trip is in between, so $1,200 for airfare

Hotel: 6 nights (Sunday - Friday) at $200 average per night (including tax).
I know, Taipei is much more than that and Vancouver, including tax, will be exactly that. However, the numbers are nice and round at $200. I often cannot afford to stay at the conference hotel; use your own numbers for your own circumstances.

Meals & Misc Expenses: $50/day for 6 days

So, the calculation is:
3x ($650 registration fee + $1,200 average airfare + $1,200 average hotel cost + $300 meals/other) = $10,050

It is critically important to note the cost is dominated by travel and hotel. The only parameter in IETF's control is the registration fee. Even if ISOC, sponsors, or someone else endowed the IETF so we could drop the registration fee to zero, the annual cost for travel is over $8,000, which is still rather expensive.

I do not believe we consciously want to prohibit individuals from participating in the IETF. I do not believe we consciously want to prohibit individuals from outside North America, Europe, and select (wealthy) Asian countries. However, this is one logical result of mandating people go to the face-to-face to get work done.

On Oct 23, 2011, at 6:26 AM, Dave CROCKER wrote:

> I've changed the subject line because the point you raise is orthogonal to the main thread, but since you raise it, it's worth exploring a bit (since I happen to agree with your observation.)
> 
> The dynamics that make this true seem to have to do with changes in our community rather than in the nature of the technical work or the online tools.
>

---

From: Ping Pan <[email-masked]>
Date: Sun, 23 Oct 2011 09:12:45 -0400

In the past three IETF meetings, I have traveled to Beijing, Prague and
Quebec City to meet most who live within a few hours (air, car, walking
etc.) from me. The next two will be in Taipei (in Winter) and Paris (in
Spring). This is more like a vacation package than a get-together for
engineers to solve problems face-to-face.

Several of us have chatted about this last week. How about this as
a recommendation?

We have two meetings in fixed locations each year: Minneapolis in winter,
and Phoenix in summer. The other one can be somewhere in Europe or Asia.

Both Minneapolis and Phoenix have huge conference facilities, are easy to
go to, and can get cheap off-season discount. Most of all,
it encourages the participants who want to do work going there.

Make sense?

Ping

On Sun, Oct 23, 2011 at 7:50 AM, Eric Burger <[email-masked]>wrote:

> It gets worse.  To attend every IETF meeting costs about $10,000 per year.
>  If we say one has to go to the face-to-face meetings, we limit the IETF to
> participants from corporations or entities that will sponsor the individual
> (pay to play?), IETF participants that have independent funds, or people
> that can generate significantly more than $10,000 per year from their IETF
> activities.  $10,000 per year is not within a typical individual's budget.
>  This is more especially so if the individual comes from a region of the
> world where the per-capita GDP is below $10,000 per year.
>
> I know, Taipei is much more than that and Vancouver, including tax, will
> be exactly that. However, the numbers are nice and round at $200. I often
> cannot afford to stay at the conference hotel; use your own numbers for
> your own circumstances.
>
> It is critically important to note the cost is dominated by travel and
> hotel. The only parameter in IETF's control is the registration fee. Even
> if ISOC, sponsors, or someone else endowed the IETF so we could drop the
> registration fee to zero, the annual cost for travel is over $8,000, which
> is still rather expensive.
>
> I do not believe we consciously want to prohibit individuals from
> participating in the IETF. I do not believe we consciously want to prohibit
> individuals from outside North America, Europe, and select (wealthy) Asian
> countries. However, this is one logical result of mandating people go to
> the face-to-face to get work done.
>
>
> > I've changed the subject line because the point you raise is orthogonal
> to the main thread, but since you raise it, it's worth exploring a bit
> (since I happen to agree with your observation.)
> >

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 23 Oct 2011 07:05:07 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Saturday, October 22, 2011 11:27 PM
> To: Melinda Shore
> Cc: [email-masked]
> Subject: Requirement to go to meetings (was: Re: Anotherj RFP without IETF community input)
> 

Tough call.  I completely understand the need and desire to be productive without requiring meetings, for all the financial, participation, and other reasons given.  But I also am very familiar with the fact that getting work done on lists can be a real challenge: People get sidetracked and can take days, weeks, or even months to answer something that's holding up a working group.

I suspect decisions get made in person because people show up, perhaps out of fear that they will have missed an opportunity to be heard or influence a key decision.  There's a feeling that meetings produce action items, where in the list environment action items get assigned when consensus gets around to warranting it.

If you're sitting on a mailing list and someone asks you to provide a document review by some date and you say nothing, there's no indication of whether or not you even got the request.  If you're sitting in a meeting room and someone asks you to provide a document review by some date, that person is likely to get an answer from you right away.

In short: Meetings don't stall, but lists do.  And I think, therefore, that many people find the meetings important, perhaps enough so that they save all their WG energy for the meetings.

I don't think it's best for maximum participation, especially given the costs of the meetings as per discussion in the other thread, but I understand why it is that way.

-MSK

---

From: Eric Burger <[email-masked]>
Date: Sun, 23 Oct 2011 14:06:20 +0000

For me, the plan outlined below changes the cost of the travel from:
	Long @ $2,000, Medium @ $1,200, and Short @ $400 = $3,600
to:
	Short @ $400, Short @ $400, Medium @ $1,200 = $2,000

HOWEVER, if I lived in Asia, the plan proposed below changes my costs from $3,600 to
	Long @ $2,000, Long @ $2,000, Medium @ $1,200 = $5,200

So, instead of someone in the U.S. paying $3,600, or about 7.5% the per-capita GDP, they can pay $2,000, or about 4% of per-capita GDP, for a reduction of travel costs of about 45%.  Along with that dramatic savings, there is a corresponding shifting of the travel burden.  Instead of someone in China paying $3,600, or about 84% of the per-capita GDP, they can pay $5,200, or about 122% of per-capita GDP, for an increase of almost 50%.  Even better, that individual most likely will have trouble getting a visa.

So, not only will we succeed in ensuring a drop-off in participation by unsponsored individuals, this would be a wonderful plan to reduce participation in the IETF by people outside of North America.

[Last I looked, reducing participation was NOT a goal of the IETF.]

On Oct 23, 2011, at 1:12 PM, Ping Pan wrote:

> In the past three IETF meetings, I have traveled to Beijing, Prague and Quebec City to meet most who live within a few hours (air, car, walking etc.) from me. The next two will be in Taipei (in Winter) and Paris (in Spring). This is more like a vacation package than a get-together for engineers to solve problems face-to-face.
> 
> Several of us have chatted about this last week. How about this as a recommendation?
> 
> We have two meetings in fixed locations each year: Minneapolis in winter, and Phoenix in summer. The other one can be somewhere in Europe or Asia.
> 
> Both Minneapolis and Phoenix have huge conference facilities, are easy to go to, and can get cheap off-season discount. Most of all, it encourages the participants who want to do work going there.
> 
> Make sense?
> 
> Ping
> 
> 
> On Sun, Oct 23, 2011 at 7:50 AM, Eric Burger <[email-masked]> wrote:

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 23 Oct 2011 10:07:35 -0400

>> considerable reservations about asking for the kind of money you're
I have been involved in the IETF for 15 years now. From my first meeting, it
was apparent to me that
"if you want to do work at the IETF, you need to go to meetings."

I wonder if in realty it has ever been different.

Regards
Marshall

>
> Melinda,
>
> I've changed the subject line because the point you raise is orthogonal to
> the main thread, but since you raise it, it's worth exploring a bit (since I
> happen to agree with your observation.)
>
> ______________________________**_________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/ietf<https://www.ietf.org/mailman/listinfo/ietf>
>

---

From: John C Klensin <[email-masked]>
Date: Sun, 23 Oct 2011 11:27:22 -0400

--On Sunday, October 23, 2011 14:06 +0000 Eric Burger
<[email-masked]> wrote:

> For me, the plan outlined below changes the cost of the travel
> from: 	Long @ $2,000, Medium @ $1,200, and Short @ $400 =
> $3,600 to:
> HOWEVER, if I lived in Asia, the plan proposed below changes
> my costs from $3,600 to 	Long @ $2,000, Long @ $2,000, Medium
> @ $1,200 = $5,200
> 
> So, instead of someone in the U.S. paying $3,600, or about
> 7.5% the per-capita GDP, they can pay $2,000, or about 4% of
> per-capita GDP, for a reduction of travel costs of about 45%.
> Along with that dramatic savings, there is a corresponding
> shifting of the travel burden.  Instead of someone in China
> paying $3,600, or about 84% of the per-capita GDP, they can
> pay $5,200, or about 122% of per-capita GDP, for an increase
> of almost 50%.  Even better, that individual most likely will
> have trouble getting a visa.

Eric,

I understand your intent and might even agree with your
conclusion, but question an analysis based on per-capita GDP.
Per-capita GDP numbers reflect population universes that are
simply irrelevant to us.  If you want to find, or invent, some
standardized salary level for those engaged in network
engineering or comparable fields, maybe.   Think about the ratio
of the number of network engineers (or equivalent) to the total
population of a country and the problem will be clear.  For this
sort of comparison, percentages of per-capita GDP are just
nonsense.  

I also note that there are some small fraction of us with
medical or other constraints that make your "long" numbers huge
underestimates.

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Sun, 23 Oct 2011 11:32:51 -0400

--On Sunday, October 23, 2011 07:05 -0700 "Murray S. Kucherawy"
<[email-masked]> wrote:

>...
> Tough call.  I completely understand the need and desire to be
> productive without requiring meetings, for all the financial,
> participation, and other reasons given.  But I also am very
> familiar with the fact that getting work done on lists can be
> a real challenge: People get sidetracked and can take days,
> weeks, or even months to answer something that's holding up a
> working group.
> 
> I suspect decisions get made in person because people show up,
> perhaps out of fear that they will have missed an opportunity
> to be heard or influence a key decision.  There's a feeling
> that meetings produce action items, where in the list
> environment action items get assigned when consensus gets
> around to warranting it.
> 
> If you're sitting on a mailing list and someone asks you to
> provide a document review by some date and you say nothing,
> there's no indication of whether or not you even got the
> request.  If you're sitting in a meeting room and someone asks
> you to provide a document review by some date, that person is
> likely to get an answer from you right away.
> 
> In short: Meetings don't stall, but lists do.  And I think,
> therefore, that many people find the meetings important,
> perhaps enough so that they save all their WG energy for the
> meetings.
> 
> I don't think it's best for maximum participation, especially
> given the costs of the meetings as per discussion in the other
> thread, but I understand why it is that way.

Murray, fwiw, your analysis doesn't require f2f meetings.  If it
could be done, well-conducted virtual/remote meetings would work
as well because they, too involve fixed cutoffs, real-time
responses, and opportunity to confront those who may not be
responding, etc.

At the other extreme, of course, we could adopt the model used
by a few other standards bodies (and perhaps left over when
"mailing list" meant "distribution of documents by post"), stop
expecting anything at all from mailing lists, and hold week-long
(or longer) meetings that the WG level in which we expected all
of the work to get done :-(

    john

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 23 Oct 2011 17:46:44 +0200

On 10/23/2011 4:07 PM, Marshall Eubanks wrote:
> I have been involved in the IETF for 15 years now. From my first meeting, it was
> apparent to me that

Yes, there has always been a tension about the proper balance between list-based 
and f2f-based work.  In recent years -- especially as we've had a greater 
proportion of people used to doing work /only/ in f2f -- we seem to rely on f2f 
more.

d/

-- 

   Dave Crocker

---

From: Scott Brim <[email-masked]>
Date: Sun, 23 Oct 2011 11:52:56 -0400

On Sun, Oct 23, 2011 at 11:46, Dave CROCKER <[email-masked]> wrote:
> Yes, there has always been a tension about the proper balance between
> list-based and f2f-based work.  In recent years -- especially as we've had a
> greater proportion of people used to doing work /only/ in f2f -- we seem to
> rely on f2f more.

Some people find it difficult to participate at a rapid pace on
mailing lists, and will strongly prefer f2f.  They might also find it
difficult to participate f2f but they can control the pace more.

---

From: Melinda Shore <[email-masked]>
Date: Sun, 23 Oct 2011 08:19:23 -0800

> So the question is how to move the center of gravity back to mailing lists?

In all honesty I'd say that the largest source of this problem is
working group chairs, both for using meetings as deadline anchors
and for doing a really crappy job managing remote participation
during meetings (and thereby increasing the need to be there in
person).  A few do an outstanding job, a few don't even try, and
most are somewhere in the middle.  It may be worth doing a wg chairs
training session on this topic during an upcoming meeting.

Melinda

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 23 Oct 2011 18:43:47 +0200

"Both Minneapolis and Phoenix have huge conference facilities, are easy
to go to, and can get cheap off-season discount" 

For whom? 

For me it is much cheaper and easier to go to Europe....:-(

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Ping Pan
Sent: Sunday, October 23, 2011 3:13 PM
To: Eric Burger
Cc: IETF list discussion
Subject: Re: Requirement to go to meetings

Several of us have chatted about this last week. How about this as a
recommendation?

We have two meetings in fixed locations each year: Minneapolis in
winter, and Phoenix in summer. The other one can be somewhere in Europe
or Asia.

Both Minneapolis and Phoenix have huge conference facilities, are easy
to go to, and can get cheap off-season discount. Most of all, it
encourages the participants who want to do work going there.

Make sense?

Ping

On Sun, Oct 23, 2011 at 7:50 AM, Eric Burger
<[email-masked]> wrote:

It gets worse.  To attend every IETF meeting costs about $10,000 per
year.  If we say one has to go to the face-to-face meetings, we limit
the IETF to participants from corporations or entities that will sponsor
the individual (pay to play?), IETF participants that have independent
funds, or people that can generate significantly more than $10,000 per
year from their IETF activities.  $10,000 per year is not within a
typical individual's budget.  This is more especially so if the
individual comes from a region of the world where the per-capita GDP is
below $10,000 per year.

Where does the $10,000 figure come from? It is based on the following
assumptions:
One trip is far, so $2,000 for airfare
One trip is near, so $400 for airfare
One trip is in between, so $1,200 for airfare

Hotel: 6 nights (Sunday - Friday) at $200 average per night (including
tax).
I know, Taipei is much more than that and Vancouver, including tax, will
be exactly that. However, the numbers are nice and round at $200. I
often cannot afford to stay at the conference hotel; use your own
numbers for your own circumstances.

So, the calculation is:
3x ($650 registration fee + $1,200 average airfare + $1,200 average
hotel cost + $300 meals/other) = $10,050

It is critically important to note the cost is dominated by travel and
hotel. The only parameter in IETF's control is the registration fee.
Even if ISOC, sponsors, or someone else endowed the IETF so we could
drop the registration fee to zero, the annual cost for travel is over
$8,000, which is still rather expensive.

I do not believe we consciously want to prohibit individuals from
participating in the IETF. I do not believe we consciously want to
prohibit individuals from outside North America, Europe, and select
(wealthy) Asian countries. However, this is one logical result of
mandating people go to the face-to-face to get work done.

On Oct 23, 2011, at 6:26 AM, Dave CROCKER wrote:

> I've changed the subject line because the point you raise is
orthogonal to the main thread, but since you raise it, it's worth
exploring a bit (since I happen to agree with your observation.)
>
> The dynamics that make this true seem to have to do with changes in
our community rather than in the nature of the technical work or the
online tools.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 23 Oct 2011 09:50:55 -0700

+1

Perhaps chairs doing an outstanding job should be singled out in some way.

See also http://jcp.org/en/press/news/star.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 23 Oct 2011 12:54:15 -0400

On Sun, Oct 23, 2011 at 12:50 PM, Marc Petit-Huguenin <[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
Or a WG training lunch on facilitating this would be in order.

Marshall

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk6kRe4ACgkQ9RoMZyVa61cwwACbBOsaPrkUYc50Fm3XYFrC7rhv
> HVsAoJY2lR0QIy4RIe/2GZmRrnCbneKj
> =cUpA
> -----END PGP SIGNATURE-----

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 23 Oct 2011 10:59:49 -0600

> training session on this topic during an upcoming meeting.

I understand your point about using the meetings as an anchor but want to dig into the managing remote participation during IETF meetings better. 

Can you give an example of chairs that do it well and what is it they do? Then perhaps contrast with what it is that chairs that do it poorly are doing. Feel free to use me as an example of a chair that does it poorly - I have no idea how to do it so it works at all much less works well.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 23 Oct 2011 18:01:02 +0100

I'm not sure I'd blame chairs so much, but anyway...

Here's a suggestion - create a list for people who are active
IETF participants but who miss a lot of meetings. (And ask people
who don't match that profile, like me, to stay out of the
discussion - we can read the archive if we're curious.) Let folks
on that list see if they can figure out things to do that they
think would make things better then bring that back here.

I'm not claiming this'd "fix" the problem, but I'd be interested
in the output and it'd avoid most of the discussion about
remote attendee things being discussed by the usual suspects
who do in fact go to most meetings afaics.

S.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 23 Oct 2011 11:18:10 -0600

The problem is that many of the things that make a meeting better for remote people, make it worse for local people. You can see that even in IETF meetings today - the virtual interim meetings were everyone is remote is a much better experience for remote people than meetings where lots of people are local in one room and some of the people are remote. 

To make any serious progress on this, I suspect we will have to discuss the trade offs of how a WG best makes progress vs fairness to people that don't/can't come. Note that depending on if you think I should have used don't or can't come in the previous sentences already highly biases the question.

---

From: Loa Andersson <[email-masked]>
Date: Sun, 23 Oct 2011 10:28:14 -0700

Nurit,

I'm in the same situation, but part of the argument is right.

If we do one North America, one Europe and one Asian meeting
per year; places like Minneapolis and Phoenix is cheaper regardless
where you come from. That is if you compare with high end cities
like SF, NY AND DC. ALso places where you need an extra hop to get
there.

/Loa

On 2011-10-23 09:43, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
> For me it is much cheaper and easier to go to Europe….:-(
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *ext Ping Pan
> *Sent:* Sunday, October 23, 2011 3:13 PM
> *To:* Eric Burger
> *Cc:* IETF list discussion
> *Subject:* Re: Requirement to go to meetings
>
> On Sun, Oct 23, 2011 at 7:50 AM, Eric Burger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> year. If we say one has to go to the face-to-face meetings, we limit the
> IETF to participants from corporations or entities that will sponsor the
> individual (pay to play?), IETF participants that have independent
>  > bbiw.net <http://bbiw.net>
>  > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 23 Oct 2011 19:32:37 +0200

For Minneapolis and Phoenix we do need extra leg as well....
And for us it is really not cheaper....

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Loa Andersson
Sent: Sunday, October 23, 2011 7:28 PM
To: [email-masked]
Subject: Re: Requirement to go to meetings

Nurit,

/Loa

> On Sun, Oct 23, 2011 at 7:50 AM, Eric Burger
<[email-masked]
> year. If we say one has to go to the face-to-face meetings, we limit
the
tax).
>  > So the question is how to move the center of gravity back to
mailing
> lists?

--

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 23 Oct 2011 18:35:27 +0100

Sure - there are other trade-offs, no doubt.  But I think
every time this topic has come up, the discussion is dominated
by people that do attend meetings, and I'd be interested in
what might come out if we tried that discussion just amongst
non-attending active participants.

If enough of 'em wanted such a list I'd be happy to get it
created. (Off list mail is fine if you just want to say you'd
subscribe.)

S.

---

From: Randy Bush <[email-masked]>
Date: Sun, 23 Oct 2011 10:47:28 -0700

perhaps we could model using the assumption that, a decade or so hence,
there will be no physical meetings, [almost] all will be net-based.

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 23 Oct 2011 11:00:44 -0700

> perhaps we could model using the assumption that, a decade or so
> hence, there will be no physical meetings, [almost] all will be
> net-based.

to make my troll more explicit (under an nsfw bridge?)
  o how does a 'town hall' of O(10^3) participants work socially?
  o how will/should incremental transition play out?
  o what are the [new] protocol needs?

randy

---

From: Melinda Shore <[email-masked]>
Date: Sun, 23 Oct 2011 10:02:44 -0800

On 10/23/11 8:59 AM, Cullen Jennings wrote:
> Can you give an example of chairs that do it well and what is
 > it they do? Then perhaps contrast with what it is that chairs
 > that do it poorly are doing. Feel free to use me as an example
 > of a chair that does it poorly - I have no idea how to do it
 > so it works at all much less works well.

It's really not that big a deal.  Make sure that audio is working,
that there's a Jabber scribe/Jabber room watcher and liaison-y sort
of person, and that remote participants are pinged regularly (and
*always* before a change of topic).  Decision questions should go
out to the list as soon as possible, if not sooner.  Make sure that
questions in the room and other discussion are audible to remote
folk.  I'm unconvinced that having video would improve anything
and while something like whiteboarding might be useful in some cases
I don't think it would be used much.  [As an aside I hope that the
RFP process doesn't result in a fancy pile of technology that looks
whizzy but doesn't actually improve meetings - I find that the
current stuff works well when the chairs are thinking about remote
participants]

There have been a few sessions where audio wasn't working and there
was nobody in the Jabber room who was in the session and could relay
that information.  One particularly badly-run session had the chairs
completely ignoring remote participants during the entire meeting and
then asking for volunteers, explicitly limiting it to people in the
room even though it was longer-term work.  (I wrote to the chairs and
ADs after that one and never heard back from anyone).

I really don't think it's that much effort and I don't think it's
disruptive, but I do think it requires of chairs a somewhat different
mental model of a meeting.

Melinda

---

From: Loa Andersson <[email-masked]>
Date: Sun, 23 Oct 2011 11:13:07 -0700

Randy,

I might be old-fashioned, but I think the net will give us more tools
that can be used together with what we already have, not (necessarily)
replace them

/Loa

--

---

From: Michal Krsek <[email-masked]>
Date: Sun, 23 Oct 2011 20:18:25 +0200

Loa,
It seems to me this is not a "tools" question. This is kind of social challenge.

M

Sent from my iPad

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 23 Oct 2011 12:36:19 -0600

> mental model of a meeting.

Ah, OK ... that sounds achievable - I certainly hope most WG these days are doing that. (and Stephen, agree with your point good to hear from people that don't god)

---

From: Tim Chown <[email-masked]>
Date: Sun, 23 Oct 2011 19:47:36 +0100

> like SF, NY AND DC. ALso places where you need an extra hop to get

+1 for Minneapolis and Prague.  Relatively large travel hubs, good venues and cheap hotels. But I understand the need to spread the venues. I recall reading thelatest attempt to secure an Asian venue led to Vancouver?

Perhaps WG chairs may consider more seriously not holding WG sessions if the agendas are very light?  At the very least that might solve the Friday problem.

But a lot is always done out of WG sessions too, which is hard to put a value on.

Tim

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 23 Oct 2011 14:55:16 -0400

2/3rds of the IETF meetings in the USA would exacerbate visa problems
for many attendees. I don't mind some amount of regularity in meeting
site, like Minneapolis, or going where it's inexpensive (by the way,
the Boston area is really cheap in the winter) but I think you need
more variety than that.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Sun, Oct 23, 2011 at 9:12 AM, Ping Pan <[email-masked]> wrote:
> Both Minneapolis and Phoenix have huge conference facilities, are easy to go
> to, and can get cheap off-season discount. Most of all,
>> cannot afford to stay at the conference hotel; use your own numbers for your
>> own circumstances.
>>
>> hotel. The only parameter in IETF's control is the registration fee. Even if
>> ISOC, sponsors, or someone else endowed the IETF so we could drop the
>> countries. However, this is one logical result of mandating people go to the
>> face-to-face to get work done.
>>
>>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 23 Oct 2011 21:34:41 +0200

Cheaper, yes. Easier?

Sure, a 5-hour flight to Paris sure beats a 12-hour flight to New York plus a 4 hour flight to Minneapolis, but you end up in Paris, and if the conference hotel is too expensive for your corporate budget (it usually is for mine), you have to go really far away to find a hotel that fits the budget and is not a fleabag. OTOH any city in the US except the really huge ones (NY or LA) you can find perfectly good hotels that feature breakfast, Internet and a spacious room for way lower than the Hilton rates, and not at all far from the conference. In Anaheim I found a hotel at half price at 10 minutes walk time from the Hilton. And maybe it's just me, but with US hotels, it's far easier to tell the fleabags from the acceptable hotels than in Europe.

Asia is even tougher. Flying to Taipei will take me to Paris and Hong Kong. And I have no idea how to tell a good hotel from a bad one. I'll have to trust the travel agent.

On 10/23/11 6:43 PM, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]<mailto:[email-masked]>> wrote:

"Both Minneapolis and Phoenix have huge conference facilities, are easy to go to, and can get cheap off-season discount"
For whom?
For me it is much cheaper and easier to go to Europe….:-(

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Ping Pan
Sent: Sunday, October 23, 2011 3:13 PM
To: Eric Burger
Cc: IETF list discussion
Subject: Re: Requirement to go to meetings

Make sense?

Ping

On Sun, Oct 23, 2011 at 7:50 AM, Eric Burger <[email-masked]<mailto:[email-masked]>> wrote:
It gets worse.  To attend every IETF meeting costs about $10,000 per year.  If we say one has to go to the face-to-face meetings, we limit the IETF to participants from corporations or entities that will sponsor the individual (pay to play?), IETF participants that have independent funds, or people that can generate significantly more than $10,000 per year from their IETF activities.  $10,000 per year is not within a typical individual's budget.  This is more especially so if the individual comes from a region of the world where the per-capita GDP is below $10,000 per year.

So, the calculation is:

On Oct 23, 2011, at 6:26 AM, Dave CROCKER wrote:

>  bbiw.net<http://bbiw.net>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Ietf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ietf

Scanned by Check Point Total Security Gateway.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 23 Oct 2011 18:54:00 -0400

>>>>> "Dave" == Dave CROCKER <[email-masked]> writes:

    Dave> On 10/21/2011 7:58 PM, Melinda Shore wrote:
    >> It's increasingly the case that if you want to do work at the
    >> IETF, you need to go to meetings. I'd have considerable
    >> reservations about asking for the kind of money you're
    >> suggesting.

    Dave> Melinda,

    Dave> I've changed the subject line because the point you raise is
    Dave> orthogonal to the main thread, but since you raise it, it's
    Dave> worth exploring a bit (since I happen to agree with your
    Dave> observation.)

Dave, count this as another area where something you seem to find
obvious is not obvious to me and kind of goes against my observations.

I think that if you want to chair a working group or bring new work to
the IETF you probably need to attend the face-to-face meetings.

I haven't seen much of a change in the above. Nor have I personally
witnessed a decline in the influence of people who attend remotely. In
working groups I follow a number of key individuals attend the meetings
less..  Some of them also spend less time on the IETF; they do seem to
have lost influence, but others who still spend significant time do not
seem to have lost influence.

So, I'm curious what observations lead people to this conclusion.

---

From: Andrew Allen <[email-masked]>
Date: Mon, 24 Oct 2011 00:44:55 +0000

Randy

I think that also assumes that the earth's rotation will also stop at some time during the next decade forcing us all to migrate to the sunny side of the planet.

Failing that happening then with 18 hours at least (Tokyo to US West coast) of time zones (and that doesnt take into account places like Hawaii and NZ) haveing any regular or long time real time sessions is in my view impractical as someone has to do it in the middle of the night then.

Andrew

----- Original Message -----
From: Randy Bush [mailto:[email-masked]]
Sent: Sunday, October 23, 2011 12:47 PM
To: Cullen Jennings <[email-masked]>
Cc: IETF Disgust <[email-masked]>
Subject: Re: Requirement to go to meetings

randy

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 23 Oct 2011 18:49:04 -0700

> So the question is how to move the center of gravity back to mailing lists?

So, I'm a co-chair of a rather busy working group with a lot of remote
participants, and I'm reasonably convinced that the center of gravity is
the mailing list, this despite occasionaly needing three meetings to get
through our agenda.

I will observe having scribed for the same working group, that remote
participation via the mailing list is a dramatically larger number of
particpants than during the meeting itself.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 23 Oct 2011 21:49:35 -0400

It can indeed be challenging, but in some circumstances, the active participants of the working group don't quite span the globe. I've also found that audio conferences seem most effective if they only last an hour or maybe 90 minutes, but are held more regularly, rather than marathon on-line interim meetings. With a 10 am ET conference slot, this probably allows 90% of the IETF attendees to participate between 7 am and 11 pm. It seems to work for many international organizations - after all, organizations with offices on the west coast of the US and in India or China are not exactly uncommon. This also seems to be a common work model for other SDOs.

If done well, this model has the advantage of avoiding the spikes in activity every three-four months. It requires an active moderator and good tools to manage hand raising and queuing, but these tools are becoming readily available even for plain audio conferences. (I like TOHRU as simple and effective.)

Rather than looking for one magic mechanism, maybe we should try to optimize the ensemble, such as:
- bug/issue trackers for the document issues late in the development cycle
- email lists for general discussion and raising issues from participants who are more peripherally engaged with a WG or document
- in-person meetings for early small-group work and establishing personal relationships
- webinar-style mechanism for plenaries and WG status updates
- regular augmented audio conferences for document-level discussions

Henning

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 23 Oct 2011 20:09:21 -0600

On 10/23/11 12:02 PM, Melinda Shore wrote:

> *always* before a change of topic).  

I have a concrete suggestion for WG chairs: don't ask for a "Jabber
scribe" (which makes it sound as if the hapless volunteer needs to type
everything that's said into the chatroom) but instead ask for someone to
relay comments from the chatroom to the mic. In my experience,
rephrasing the request in this way always results in a volunteer.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 24 Oct 2011 07:43:35 +0200 (CEST)

> difficult to participate f2f but they can control the pace more.

I've been a fairly passive meeting participant in IETF as of a few years, 
only been to one meeting. I don't know where work is being done at the 
meetings, but for some WGs with a lot of work, the official meetings are 
not that helpful. No real discussion can be had because of time 
constraints, and who can iron out a controvesial topic in a couple of 
hours anyway, much less 5 or 10 topics? I guess a lot of work is being 
done over lunch and dinner?

I feel this is a matter of culture and how people are used to work. I 
started using FIDONET in the 80ties, for me eletronic communication and 
managing lots of email is not a problem. I see other people claiming 
seldom reading the mailinglist discussions but instead only read drafts. 
Drafts for me is a good way to "sum up" a discussion, but discussing via 
writing drafts isn't really a discussion. I'd rather write a "summary" to 
the list, see if people are interested and if things make sense on a high 
level, and THEN perhaps a draft can be written. Spending time to write a 
proper draft (which takes a lot of time if it's your first time) and just 
having it rejected as a bad idea outright is a waste of time for 
everybody.

The WGs I participate in seem fine to work in without going to meetings 
though. I'm happy for that.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Sun, 23 Oct 2011 22:53:19 -0700

i live in tokyo and participate in three or more continent (NA, Euro,
Asia) calls a number of times a week.  i am currently one quarter of the
way through an eight week four continent rtw (with south africa after
taipei).  and it ain't my first this year.  boo hoo.

get real here.  we want global participation.  the world is big and the
world is round.  you gonna pay for it with jet lag, con calls at weird
hours, or both.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 24 Oct 2011 08:45:04 +0200

> world is round.  you gonna pay for it with jet lag, con calls at weird

Or none ... there is simple solution like meeting recording, but for 
some reason IETF proceedings are very crappy in linking wg meetings to 
their recordings (if at all available).

Example: Quebec City ISIS WG meeting

http://www.ietf.org/proceedings/81/isis.html

3 drafts presented ... looking at link to audio there is zoo of mp3 
without even containing the name of wg in their filename:

http://www.ietf.org/audio/ietf81/

Can one perhaps take an action to improve this starting Taipei ?

Best,
R.

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 24 Oct 2011 00:45:48 -0700

> Can one perhaps take an action to improve this starting Taipei ?

the ietf 81 recordings have a substantially more normalized name format
than previously for which you can thank the folks from verilan for the
tool development.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 24 Oct 2011 01:33:58 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Petit-Huguenin
> Sent: Sunday, October 23, 2011 9:51 AM
> To: Melinda Shore
> Cc: [email-masked]; [email-masked]

Ditto.  I really like that idea.

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 24 Oct 2011 09:26:31 +0200

On 21/10/2011 16:54, Simon Pietro Romano wrote:

> I can state for sure that we have used Meetecho for remote presentations in
> Hiroshima, in the mediactrl WG meeting: interaction happens in real-time.

Actually, this is true for all tools that I've seen, but it isn't perfect
yet and I wonder if it will ever be.

Henk

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 24 Oct 2011 14:37:37 +0200

On 10/24/2011 4:09 AM, Peter Saint-Andre wrote:
>> that there's a Jabber scribe/Jabber room watcher
...
> relay comments from the chatroom to the mic.

Basic question:  what has been the claimed purpose for doing jabber scribing?

I thought it was a means of produce raw minutes.  A side -- and sometimes 
extremely valuable -- benefit is as a relatively real-time alternative source of 
information about what is being spoken; this can be quite helpful for 
participants who are not native English speakers.

If neither of these purposes are worth the effort, then your suggestion sounds 
dandy.  If either is sufficiently valuable, then my question is why your groups 
haven't needed them.  (I'm expecting the answer to be that your groups didn't 
feel the need; so my real question is why not?)

d/

-- 

   Dave Crocker

---

From: Kevin Smith <[email-masked]>
Date: Mon, 24 Oct 2011 13:44:04 +0100

On Mon, Oct 24, 2011 at 1:37 PM, Dave CROCKER <[email-masked]> wrote:
> extremely valuable -- benefit is as a relatively real-time alternative
> source of information about what is being spoken; this can be quite helpful
> for participants who are not native English speakers.
>
> If neither of these purposes are worth the effort, then your suggestion
> sounds dandy.  If either is sufficiently valuable, then my question is why
> your groups haven't needed them.  (I'm expecting the answer to be that your
> groups didn't feel the need; so my real question is why not?)

FWIW, I've found Jabber scribes supplementing the audio stream useful
because the audio stream alone isn't always sufficient to hear what's
going on, or to know who's speaking.

/K

---

From: John Leslie <[email-masked]>
Date: Mon, 24 Oct 2011 08:46:22 -0400

John C Klensin <[email-masked]> wrote:
>> ... I also am very familiar with the fact that getting work done
>> on lists can be a real challenge: People get sidetracked and can
>> take days, weeks, or even months to answer something that's
>> holding up a working group.

   But _why_ is that something "holding up a working group"?

>> likely to get an answer from you right away.

   But is that "right-away" answer necessarily useful?

>> In short: Meetings don't stall, but lists do.

   I have seen many meeting stall. :^(

   Fortunately, they end. ;^)

   We're stuck with human nature here, and human nature tends to
put things off until the "last minute". Meetings "work better"
because they start and end at known times.

> responses, and opportunity to confront those who may not be

   I bring to your attention an existence proof: the IESG.

   For years they've been doing the vast bulk of entirely-too-much
work over "telechats". They _have_ fixed cutoffs, real-time
responses, and bi-weekly opportunities to confront those who may
not be responding. Et cetera...

   IMHO, we shouldn't dwell on why face-to-face meetings work better:
we should admit they really don't work well enough.

   I follow far too many (heck, one would be too many!) WGs where
the only cutoff is the I-D submission deadline before IETF week.
We're all seeing the ritual announcement in WG lists right now:
"If you'd like to present something, tell us!"

   WG chairs put so much effort into trying to make IETF-week
meetings work well that you really can't blame them for relaxing
a bit after IETF week completes. But too often, the momentum is
lost: WGCs have assigned responsibilities to folks who did show
up; and they too are exhausted by the end of IETF week. Finally,
they are roused by the I-D submission deadline for the next IETF
week.

   :^(

   I follow other WGs where there are Interim Meetings. The result
is much happier -- quite possibly _mostly_ because of the added
cutoff.

   Admittedly, the face-to-face Interims work better than virtual
Interims; but I'm not convinced that would still be the case if
instead of one face-to-face we had three or more virtual Interims.
There is a definite learning-curve working with conferencing
software, but once you've climbed this it works well enough. And
the additional cutoffs, IMHO, accomplish almost as much as the
meetings themselves! ;^)

   My advice is to put more effort into formal scheduling of
Interim meetings (probably mostly virtual Interims). Currently
these are treated as exceptional events needing AD approval:
while I agree AD-approval probably belongs there, I'd wish we
could treat them as "normal" events.

--
John Leslie <[email-masked]>

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 24 Oct 2011 08:49:21 -0400

> for participants who are not native English speakers.
That is how I use it. In that interpretation, there only needs to be one
scribe, with is an advantage.

Another BIG advantage of this is that if I write (as a jabber scribe)
something like

Audience member ? : this proposal conflicts with RFC <mumble>

I am likely to get a rapid response providing what <mumble> means and who
the speaker is. After the fact, this sort of thing is much harder to
reconstruct.

A disadvantage is that it typically overwhelms normal discussion on the
jabber channel. I have suggested that each
session get _2_ jabber channels, one for chat, one for scribing, but so far
this has not gotten any support.

Regards
Marshall

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 24 Oct 2011 08:49:51 -0400

On Oct 24, 2011, at 8:37 AM, Dave CROCKER wrote:

> I thought it was a means of produce raw minutes.  A side -- and sometimes extremely valuable -- benefit is as a relatively real-time alternative source of information about what is being spoken; this can be quite helpful for participants who are not native English speakers.
> 
> If neither of these purposes are worth the effort, then your suggestion sounds dandy.  If either is sufficiently valuable, then my question is why your groups haven't needed them.  (I'm expecting the answer to be that your groups didn't feel the need; so my real question is why not?)

	The problem with Jabber is that it has become an apparently replacement for audio/video conversation/Q&A at WG meetings for remote participants.   I find the jabber feed to be relatively useless at meetings for this purpose as the chairs do not always notice questions. Using something like WebEx is far more useful, and I'd suggest making it mandatory for all WG meetings in the near future to better facilitate remote participants.

	--Tom

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 24 Oct 2011 08:52:54 -0400

On Mon, Oct 24, 2011 at 8:49 AM, Thomas Nadeau <[email-masked]>wrote:

>         The problem with Jabber is that it has become an apparently
> replacement for audio/video conversation/Q&A at WG meetings for remote
> participants.   I find the jabber feed to be relatively useless at meetings
> for this purpose as the chairs do not always notice questions. Using
> something like WebEx is far more useful, and I'd suggest making it mandatory
> for all WG meetings in the near future to better facilitate remote
> participants.
>
>
As jabber scribe, I view part of my responsibility as relaying questions
asked on jabber (if no one else is doing so). For groups that have
secretaries, I suggest that that be part of the secretary's
responsibilities.

Regards
Marshall

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 24 Oct 2011 05:55:58 -0700

On 10/24/11 05:49 , Thomas Nadeau wrote:
>>>> It's really not that big a deal.  Make sure that audio is
>>>> working, that there's a Jabber scribe/Jabber room watcher
>> ...
>>> I have a concrete suggestion for WG chairs: don't ask for a
>>> "Jabber scribe" (which makes it sound as if the hapless volunteer
>>> needs to type everything that's said into the chatroom) but
>>> instead ask for someone to relay comments from the chatroom to
>>> the mic.
>> 
>> 
>> I thought it was a means of produce raw minutes.  A side -- and
>> sometimes extremely valuable -- benefit is as a relatively
>> real-time alternative source of information about what is being
>> spoken; this can be quite helpful for participants who are not
>> native English speakers.
>> 
>> If neither of these purposes are worth the effort, then your
>> suggestion sounds dandy.  If either is sufficiently valuable, then
>> my question is why your groups haven't needed them.  (I'm expecting
>> the answer to be that your groups didn't feel the need; so my real
>> question is why not?)
> 
> replacement for audio/video conversation/Q&A at WG meetings for
> remote participants.   I find the jabber feed to be relatively
> useless at meetings for this purpose as the chairs do not always
> notice questions. Using something like WebEx is far more useful, and
> I'd suggest making it mandatory for all WG meetings in the near
> future to better facilitate remote participants.

http://www.ietf.org/mail-archive/web/vmeet/current/msg00232.html

> --Tom
> 
> 
>> 
>> d/
>> 
>> --
>> 
>> Dave Crocker Brandenburg InternetWorking bbiw.net 
>> _______________________________________________ Ietf mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/ietf
>> 
> 
> _______________________________________________ Ietf mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Oct 2011 15:08:45 +0200

>	Cheaper, yes. Easier?
>
>	Sure, a 5-hour flight to Paris sure beats a 12-hour flight to New York plus a 4 hour flight to 
>	Minneapolis, but you end up in Paris, and if the conference hotel is too expensive for your 
>	corporate budget (it usually is for mine), you have to go really far away to find a hotel that 
>	fits the budget and is not a fleabag. OTOH any city in the US except the really huge ones 
>	(NY or LA) you can find perfectly good hotels that feature breakfast, Internet and a spacious 
>	room for way lower than the Hilton rates, and not at all far from the conference. In Anaheim 
>	I found a hotel at half price at 10 minutes walk time from the Hilton. And maybe it's just me, 
>	but with US hotels, it's far easier to tell the fleabags from the acceptable hotels than in 
>	Europe.
>
>	Asia is even tougher. Flying to Taipei will take me to Paris and Hong Kong. And I have no 
>	idea how to tell a good hotel from a bad one. I'll have to trust the travel agent.

...or TripAdvisor.

People from other parts of the world probably have the same problem when travelling to US, but with a little bit of research effort I think it's pretty easy to get a picture of the hotel, how far it is from the meeting etc.

Regards,

Christer

---

From: John Leslie <[email-masked]>
Date: Mon, 24 Oct 2011 09:10:41 -0400

Henk Uijterwaal <[email-masked]> wrote:
>> I can state for sure that we have used Meetecho for remote
>> presentations in Hiroshima, in the mediactrl WG meeting: interaction
>> happens in real-time.

   I don't have enough experience with Meetecho to guess what
"real-time" means here. I have heard folk seriously claim that
ten-second delay is still "real-time".

> Actually, this is true for all tools that I've seen, but it isn't
> perfect yet and I wonder if it will ever be.

   "Perfect" probably isn't a useful concept. Brian Rosen tells us that
150 milliseconds is "barely good enough" -- in my experience there's
a great-wall-of-china effect at about one-second delay: when it goes
beyond that folks get really exasperated trying to get their ideas
out in a timely fashion.

   150 milliseconds is a real challenge to accomplish worldwide, though
it's quite achievable within one continent. I expect IETF folks could
learn to work with 250 milliseconds.

   But terms like "real-time" and "perfect" don't help. Can we avoid
them?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 24 Oct 2011 15:24:48 +0200 (CEST)

> learn to work with 250 milliseconds.

Are these numbers RTT or one-way? According to figures I've seen in other 
contexts, most people are fine with 400ms RTT (this is a quite common 
delay just talking mobile phone-to-phone even in the same city), but 
people really start to notice around 500-700ms RTT. 1 second RTT is really 
noticable, but still workable with some practice.

It's hard to have a heated argument over more than 400-500 ms RTT though, 
so it depends on what kind of discussions are to be had :P

Ground/sea based fiber optical cable networks rarely give more than 500ms 
RTT, so anyone fairly well connected to the worldwide Internet via ground 
based infrastructure should be able to participate with less than 1s RTT 
including encoding delays etc, at least if the system is located at the 
same place or fairly close to the venue (at least so the signal doesn't 
have to be bounced half way around the world before it's sent to the final 
destination).

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 24 Oct 2011 09:37:40 -0400

On Mon, Oct 24, 2011 at 9:24 AM, Mikael Abrahamsson <[email-masked]>wrote:

>   150 milliseconds is a real challenge to accomplish worldwide, though it's
>> quite achievable within one continent. I expect IETF folks could learn to
>> work with 250 milliseconds.
>>
>
> contexts, most people are fine with 400ms RTT (this is a quite common delay
> just talking mobile phone-to-phone even in the same city), but people really
> start to notice around 500-700ms RTT. 1 second RTT is really noticable, but
> still workable with some practice.
>
> including encoding delays etc, at least if the system is located at the same
> place or fairly close to the venue (at least so the signal doesn't have to
> be bounced half way around the world before it's sent to the final
> destination).
>

Long experience with telepresence shows that formal meetings (where you have
to wait your turn, there is a moderator or chair, etc) work pretty well with
long latencies. It is  person to person interactions that start to suffer
above about 400 msec (there is research on this from Bell Labs going back I
believe into the 1960's). IETF meetings are fairly formal in this sense, so
we should be able to tolerate latencies.

Regards
Marshall

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 24 Oct 2011 15:39:12 +0200

On 10/24/2011 2:49 PM, Thomas Nadeau wrote:
> I find the jabber feed to be relatively useless at meetings for this purpose as the chairs do not always notice questions.

This goes back to the question of methodology for chairing group activities, 
whether f2f or on a mailing list.

In special cases, a group does not need to be (actively) managed (e.g., by a 
chair) but normally it does.  The rest of the time, active management is 
essential, which then leads to the question of methodology.

A small, well-behaved, knowledgeable group, working on a reasonably 
well-understood topic, typically needs minimal management.  The IETF does 
sometimes have such a group, but not often.

Large, well-behaved groups that are motivated to make progress typically need 
only basic, textbook process management methods.

Less well-behaved groups needs stricter management.  Predictably this is where 
we tend to see large differences among chair skillsets.  (The challenge is both 
being willing to be strict, and the particular methods used for strictness.)

What is being layed on top of this range, here, is the multi-media challenge of 
remote/local participation.  As noted, that's a matter of attention to the fact 
of this challenge and adjusting.

Simplistically, my own observation is that when chairs put energy into worrying 
about including remote participants -- unless the room is cantankerous -- things 
go rather better for the remote folk.  When the chairs do no pay ongoing 
attention to the inclusion of remote folk, then the remote folk lose.

Tools might help this, but it won't fix it.

d/
-- 

   Dave Crocker

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Oct 2011 10:22:57 -0400

>> I find the jabber feed to be relatively useless at meetings for
    >> this purpose as the chairs do not always notice questions. 

    Dave> This goes back to the question of methodology for chairing group activities,
    Dave> whether f2f or on a mailing list.

    Dave> In special cases, a group does not need to be (actively) managed (e.g., by a
    Dave> chair) but normally it does.  The rest of the time, active management is
    Dave> essential, which then leads to the question of methodology.

    Dave> A small, well-behaved, knowledgeable group, working on a reasonably
    Dave> well-understood topic, typically needs minimal management.  The IETF does
    Dave> sometimes have such a group, but not often.

    Dave> Large, well-behaved groups that are motivated to make progress typically need
    Dave> only basic, textbook process management methods.

    Dave> Less well-behaved groups needs stricter management.  Predictably this is
    Dave> where we tend to see large differences among chair skillsets.  (The challenge
    Dave> is both being willing to be strict, and the particular methods used for
    Dave> strictness.)

    Dave> What is being layed on top of this range, here, is the multi-media challenge
    Dave> of remote/local participation.  As noted, that's a matter of attention to the
    Dave> fact of this challenge and adjusting.

    Dave> Simplistically, my own observation is that when chairs put energy into
    Dave> worrying about including remote participants -- unless the room is
    Dave> cantankerous -- things go rather better for the remote folk.  When the chairs
    Dave> do no pay ongoing attention to the inclusion of remote folk, then the remote
    Dave> folk lose.

My belief is that a properly done (researched and taught, with some
technology to help reinforce the social contract) remote participation
process will in fact *help* weaker chairs deal with less well-behaved
groups.

I'm claiming that not only do remote folks benefit, but local folks
benefit too!

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: John Leslie <[email-masked]>
Date: Mon, 24 Oct 2011 10:42:04 -0400

Mikael Abrahamsson <[email-masked]> wrote:
> Are these numbers RTT or one-way?

   I'm embarrassed to admit I don't know which Brian Rosen meant: perhaps
he'll elaborate. He may well have meant one-way delay plus codec delay
plus application delay.

> According to figures I've seen in other contexts, most people are fine
> with 400ms RTT (this is a quite common delay just talking mobile
> phone-to-phone even in the same city),

   I'm pretty sure what I've observed mobile-to-mobile exceeds Brian's
criteria...

> but people really start to notice around 500-700ms RTT. 1 second RTT
> is really noticable, but still workable with some practice.

   _I_ certainly notice before 500 msec RTT-plus-codec.

   I don't think I agree that 1 second RTT-plus-codec is workable in
groups where any of a half-dozen folks might speak at any time.

> It's hard to have a heated argument over more than 400-500 ms RTT

   Exactly!

> so it depends on what kind of discussions are to be had :P

   It wouldn't be IETF without an occasional heated-discussion!

> Ground/sea based fiber optical cable networks rarely give more than
> 500ms RTT, so anyone fairly well connected to the worldwide Internet
> via ground based infrastructure should be able to participate with
> less than 1s RTT including encoding delays etc,

   There's no reason why ground/sea based fibre needs to exceed about
200 msec RTT; but buffer-bloat does cause this sometimes. In practice,
business-level Internet is likely to add 100 msec to this, and cable
Internet can add considerably more. :^(

> at least if the system is located at the same place or fairly close
> to the venue

   (I'm guessing you mean a single-central-server through which all
audio passes.)

> (at least so the signal doesn't have to be bounced half way around
> the world before it's sent to the final > destination).

   I don't honestly know how flexible the various vendor systems are
in that respect. I would like to believe they are capable of more
intelligent switching than that...

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 24 Oct 2011 11:47:55 -0400

> he'll elaborate. He may well have meant one-way delay plus codec delay

The speed of light in optical fibers (index of refraction ~ 1.5) means that
the one way time from any place on Earth to its antipode must be >~ 100
milliseconds, so I think that the above must be one way times.

300 to 400 milliseconds to the antipodes and back (i.e., RTT) is pretty
realistic (say, US to Australia*). To that has to be added codec delays
(each frame of 30 fps video represents ~30 msec);100+ msec one way video
codec delays are common. If you add all of that up, you get enough latency
that it begins to be noticeable, even in a formal meeting, for links such as
US-India and US-Australia.

Regards
Marshall

*The closest to truly antipodal pair of places I know of in common use are
Hawaii to South Africa. If anyone has measured  RTTs for that I would be
curious to know them.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Oct 2011 09:57:57 -0600

> going on, or to know who's speaking.

Problem is, it's a lot of work to scribe the audio, and it's not easy to
find volunteers for that task. I do think it's helpful for someone to at
least relay the names of those who step up to the mic, but that could be
done with those little RFID badges we experimented with a few times.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 24 Oct 2011 11:36:40 -0500

For what it's worth, I've been a repeat-offender note-taker for a bunch of 
groups at the IETF, and was doing that when we mass-created all the 
jabber.ietf.org rooms.

It was obvious to me at that time (but I was wrong) that I should be 
continuing to take notes in the jabber room, so people had the chance to 
correct things I wasn't getting right, but the volume of my notes swamped 
the ability of anyone else to use the jabber room for discussion, asking 
questions, raising hands ...

This was true for working group meetings, virtual interim meetings, the IESG 
telechats, and plenaries (so, across the board).

There were several IETFs where there were two jabber rooms (one for sessions 
I was note-taking for, and one for other uses) for RAI working groups I was 
note-taking for, but that happened two or three years ago, and I haven't 
seen any meetings with two jabber rooms lately.

Spencer

----- Original Message ----- 
From: "Peter Saint-Andre" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 24, 2011 10:57 AM
Subject: Re: Requirement to go to meetings

>>> sometimes

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Oct 2011 10:41:36 -0600

On 10/24/11 10:36 AM, Spencer Dawkins wrote:

> correct things I wasn't getting right, but the volume of my notes
> swamped the ability of anyone else to use the jabber room for
> discussion, asking questions, raising hands ...

IMHO, something like Etherpad is better than a chatroom for
collaborative note-taking.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 24 Oct 2011 11:56:41 -0500

We've come a long way.

That would make sense to me.

Spencer

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Oct 2011 10:58:21 -0600

I've used it for various meetings (e.g., W3C/IETF coordination calls)
and it's super. I've suggested to the tools team that they look into
installing an instance.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 24 Oct 2011 19:13:25 +0200 (CEST)

> US-India and US-Australia.

Yes, that is my understanding as well, I seldom see more than ~400ms RTT 
(all bets are off when there is buffering of course) to anywhere in the 
world. Some of the worst are when it's going longer than antipode, ie 
Europe->US->Japan->Singapore, but usually even with that it's around 400ms 
when it's at its worst.

I'd say that considering network delay is 400ms RTT, that means with 
codec delays etc this can be made to work at formal meetings. It's not the 
same as being in the room, but it can be made to work (if the analogy is 
to walk up to the mic and make a statement instead of having an argument).

Then again, I don't know how much this will help since I blieve a lot of 
work is not being done in the meetings, but in f2f discussions outside of 
meetings?

---

From: SM <[email-masked]>
Date: Mon, 24 Oct 2011 10:16:24 -0700

At 05:52 24-10-2011, Marshall Eubanks wrote:
>As jabber scribe, I view part of my responsibility as relaying 
>questions asked on jabber (if no one else is doing so). For groups 
>that have secretaries, I suggest that that be part of the 
>secretary's responsibilities.

The secretary is busy taking minutes.  That doesn't mean that the 
secretary cannot draw attention if someone is asking a question on 
Jabber.  The audio recording is a handy supplement when the speaker 
cannot be identified or to cross-check the details.

As for remote participation, if you do not know anyone in the room 
you are going to be ignored.  That's an IETF feature that also 
applies for people who attend meetings.  There are little things that 
can help remote participants follow what is going on.  Melinda Shore 
mentioned some of them.  Most of the fixes are non-technical.

If you do not go to meetings, it's unlikely that you will be able to 
follow the BoF you are interested in.  There may be times when 
decisions are taken during a meeting.  It is not worth the 
nit-picking if the outcome won't change.

Regards,
-sm

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 24 Oct 2011 13:49:02 -0400

>> As jabber scribe, I view part of my responsibility as relaying questions asked on jabber (if no one else is doing so). For groups that have secretaries, I suggest that that be part of the secretary's responsibilities.
> 
> The secretary is busy taking minutes.  That doesn't mean that the secretary cannot draw attention if someone is asking a question on Jabber.  The audio recording is a handy supplement when the speaker cannot be identified or to cross-check the details.

	In my experience that unfortunately happens about %10 of the time.  We need some way for remote participants to virtually stand in the mic queue so they get called upon and allowed to not only ask a question, but to follow-up - especially if the presenter needs clarification on the question.

> As for remote participation, if you do not know anyone in the room you are going to be ignored.  That's an IETF feature that also applies for people who attend meetings.  There are little things that can help remote participants follow what is going on.  Melinda Shore mentioned some of them.  Most of the fixes are non-technical.

	Jabber/etc... are really bubblegum and bailing wire solutions.  I have been forced to skip meetings in the past due to budget issues, and can tell you that relying on others to proxy for you just doesn't work. Despite knowing someone in the room, you are assuming they are not busy trying to work themselves either participating in the meeting, writing documents, or whatever.  I've tried Skyping into meetings, jabber, whatever and it just doesn't work well because the people that ultimately must speak for you often can't.  Also, you assume people know someone well enough to ask for them; which is asking a lot especially for new people.

	The best approach I've witnessed (and used many times) is WebEx where you can explicitly request to ask a question by virtually raising your hand, and then when the chair recognizes you, you can ask your own question. You can then interact with the presenter - and if the chairs are being sophisticated, they could project your face on a screen.  You can also use this mechanism as a means when gauging consensus where the chair(s) ask for a feeling of the room and for people to raise their hands.   

	--Tom

> 
> If you do not go to meetings, it's unlikely that you will be able to follow the BoF you are interested in.  There may be times when decisions are taken during a meeting.  It is not worth the nit-picking if the outcome won't change.
> 
> Regards,
> -sm

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Oct 2011 14:17:58 -0400

>>>>> "sm" == sm  <[email-masked]> writes:
    sm> If you do not go to meetings, it's unlikely that you will be able to follow
    sm> the BoF you are interested in.  There may be times when decisions are taken
    sm> during a meeting.  It is not worth the nit-picking if the outcome won't
    sm> change.

If you are claiming that remote participation for BOFs is more
challenging, then I *strongly* agree.  

Much of the problem is not technical, but administrative (agendas and
materials being incomplete), and also proceedural (many many more
cross-microphone discussions, etc.)

The biggest challenge is however that we are seeing a massive increase
in "Bar-BOFs"... it's one thing if 5 people get together to figure out a
problem statement, it's another when it's announced...

---

From: Melinda Shore <[email-masked]>
Date: Mon, 24 Oct 2011 10:35:25 -0800

> problem statement, it's another when it's announced...

Yes!  As a process matter I'd be happy to see "Bar BOFs" go away
as a supported activity.  I'm unclear on why writing up a problem
statement and trying to gin up discussion on a mailing list is
no longer sufficient, but I think it's pretty clearly a symptom
of process drift.

I tend to think the whole clouds/data center mishegas would be
going a lot better if they'd followed the conventional process
and started with a problem definition (and scoping, for Pete's
sake: *scoping*) rather than giving a bunch of non-technical
presentations at so-called "Bar BOFs," trying to develop interest.
I could be wrong but my sense is that the semi-recognized
partly-supported somewhat-organized insufficiently-coherent
inching-towards-acceptance Bar BOF structure provides a
little too much organizational support for ideas that are less
than fully-formed.  And yeah, since remote meeting tools aren't
provided (audio, in particular) people do need to attend in
person if they want to participate in one of those things.

Melinda

---

From: "Robin Uyeshiro" <[email-masked]>
Date: Mon, 24 Oct 2011 18:32:24 -1000

Here's another post out of left field.

It seems to me that in order to solve the problem of remote participation in
meetings, we need to decide what it means to participate in a meeting.  It
seems to me that the important characteristic of a meeting is that one
person speaks at a time.  In WG meetings, one person presents and then
others que up at a mic for comments/questions.  The issues I've seen only
relate to the comment/question part.  

One group of comments deals with the difficulty of the current jabber setup
to allow comments/questions to become the focus, the "one person speaking".
Perhaps this could be worked out with some kind of enforced protocol, such
that mic speakers' questions/comments are interleaved with jabber
questions/comments in some way.  I think, though, it would be harder to
follow threads of thought in this way, especially if there are many jabber
questions/comments that come in on a specific topic while mic speakers start
to follow a different issue.  Some kind of policing where issues are
discussed sequentially might help, but might be too restricting.  Maybe it
would be better to take thread discussions off the mic at some point and use
some kind of forum software?

A second problem is the use of jabber to discuss offline what speakers are
discussing.  It seems to me that this is a direct contradiction to what is
supposed to occur in a meeting, where one person speaks at a time.  

I've never used Webex, so I can't comment on its applicability.  It seems to
me that jabber is not the right tool for remote meeting participation.  It
probably works fine for meeting monitoring along with the audio, but seems
to fall short for remote meeting participation without some kind of enforced
meeting protocol.  Is what Melinda described enough?  Should there be some
kind of media Sargent-At-Arms enforcing Robert's 21st Century Rules?  

Jabber seems to be important for the scribe task.  That's not something to
be taken lightly.  In fact, the whole issue of what the meeting record
should be is taken too lightly, in my opinion.  Should it be the audio with
scribe comments, plus the Jabber record?  If that's the case, a person
looking up the meeting would need the audio and the scribe/jabber comments.
Should it be the scribe notes, which can be undependable, even with the
jabber comments?  Should we be looking at voice-to-text more seriously?

Seems to me that this is a universal problem that someone should have
solved.  If not, it's a great opportunity.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thomas Nadeau
Sent: Monday, October 24, 2011 7:49 AM
To: SM
Cc: [email-masked]
Subject: Re: Requirement to go to meetings

> The secretary is busy taking minutes.  That doesn't mean that the
secretary cannot draw attention if someone is asking a question on Jabber.
The audio recording is a handy supplement when the speaker cannot be
identified or to cross-check the details.

	In my experience that unfortunately happens about %10 of the time.
We need some way for remote participants to virtually stand in the mic queue
so they get called upon and allowed to not only ask a question, but to
follow-up - especially if the presenter needs clarification on the question.

> As for remote participation, if you do not know anyone in the room you are
going to be ignored.  That's an IETF feature that also applies for people
who attend meetings.  There are little things that can help remote
participants follow what is going on.  Melinda Shore mentioned some of them.
Most of the fixes are non-technical.

	Jabber/etc... are really bubblegum and bailing wire solutions.  I
have been forced to skip meetings in the past due to budget issues, and can
tell you that relying on others to proxy for you just doesn't work. Despite
knowing someone in the room, you are assuming they are not busy trying to
work themselves either participating in the meeting, writing documents, or
whatever.  I've tried Skyping into meetings, jabber, whatever and it just
doesn't work well because the people that ultimately must speak for you
often can't.  Also, you assume people know someone well enough to ask for
them; which is asking a lot especially for new people.

	The best approach I've witnessed (and used many times) is WebEx
where you can explicitly request to ask a question by virtually raising your
hand, and then when the chair recognizes you, you can ask your own question.
You can then interact with the presenter - and if the chairs are being
sophisticated, they could project your face on a screen.  You can also use
this mechanism as a means when gauging consensus where the chair(s) ask for
a feeling of the room and for people to raise their hands.   

	--Tom

> If you do not go to meetings, it's unlikely that you will be able to
follow the BoF you are interested in.  There may be times when decisions are
taken during a meeting.  It is not worth the nit-picking if the outcome
won't change.

---

From: "t.petch" <[email-masked]>
Date: Tue, 25 Oct 2011 09:47:46 +0200

----- Original Message ----- 
From: "Melinda Shore" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, October 23, 2011 6:19 PM
Subject: Re: Requirement to go to meetings

> training session on this topic during an upcoming meeting.

Yup, and not just managing remote participation.  The mailing list 
work of the IETF consists, for many WGs, of
three short bursts of activity each year, interspersed with periods of
hibernation (or aestivation).

Perhaps we should schedule six meetings each year; no need to attend
them, it would just create six bursts of activity each year so we would 
get twice as much done, or get the same amount done in half the time.

When W S Gilbert's song, "I've got a little list, they'd none of them
be missed" is updated in modern performances, I would like to add
to the list WG chairs who go to sleep between meetings:-)

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Tue, 25 Oct 2011 09:58:15 +0200

----- Original Message ----- 
From: "John Leslie" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 24, 2011 2:46 PM
>    But _why_ is that something "holding up a working group"?

Because they are the one holding the token, usually the editorship of
the I-D, and everyone else must wait for a revised version, for a
response to LC comments etc.   Harking back to Melinda's comment,
this is where chairmanship comes in; the good chairs will chivy, poke
and prod so that the hold-ups are minimised, or will kick off something
else in the meantime.  And sometimes WG chairs should prod ADs, 
sometimes vice versa.  What is difficult in our structure is for those
without a formal role to insert a chivy without causing offence; this is
where face-to-face, with its vastly richer communication channel, is
superior.

Tom Petch

---

From: John Leslie <[email-masked]>
Date: Tue, 25 Oct 2011 11:06:00 -0400

t.petch <[email-masked]> wrote:
> response to LC comments etc.

   This is _not_ a good way to run a mailing-list!

> Harking back to Melinda's comment, this is where chairmanship comes
> in; the good chairs will chivy, poke and prod so that the hold-ups
> are minimised...

   The WGC cannot always manage this alone...

> And sometimes WG chairs should prod ADs, sometimes vice versa.

   ADs don't have as much time available for this as you think...

> What is difficult in our structure is for those without a formal role
> to insert a chivy without causing offence;

   A "chivy", almost by definition, is bound to cause offense. But
a posted question, expecting an answer from a WGC, can be effective.

> this is where face-to-face, with its vastly richer communication
> channel, is superior.

   True, but three times a year isn't often enough. :^(

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 25 Oct 2011 16:25:43 +0100

Marshall Eubanks

>The closest to truly antipodal pair of places I know of in common use
are Hawaii to South Africa.
 
http://en.wikipedia.org/wiki/Antipodes has lists of alternatives.
(Verify before use.)

-- 
Christopher Dearlove
Technology Leader, Communications Group
Communications and Networks Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Ping Pan <[email-masked]>
Date: Tue, 25 Oct 2011 08:55:10 -0700

> person if they want to participate in one of those things.
Well, I think this actually illustrates why we do need to go to meetings
in-person. Typically, unless one has read the relevant drafts and studied
the issues ahead of time, it's hard to go to a meeting and have an in-depth
understanding from 5-10 minuets of presentation. So, many of us go to
meetings to listen and to participate on the topics we actually know and
care. At the same time, we often get surprised by the new ideas either from
the presentations or the discussion on the mic. This is the time for hallway
chat. Sometime, we simply go and bounce new ideas with others.

I think that meeting people and having face-to-face discussion have been one
of the key motivations for many of us going to IETF in the first place. The
location of the meeting is actually secondary in comparison.

So, yes, remote conferencing tool is needed, better meeting notes would be
useful, but the original issue remains: please make IETF meetings easier and
cheaper for us to go to. ;-)

Regards,

Ping

---

From: Fred Baker <[email-masked]>
Date: Tue, 25 Oct 2011 10:19:21 -0700

On Oct 25, 2011, at 8:55 AM, Ping Pan wrote:

>  the original issue remains: please make IETF meetings easier and cheaper for us to go to. ;-)

I think that a lot of people would like that. There are a number of problems that need to be solved to make them cheaper to attend.

One is the issue of air fare and hotel cost; these have been brought up before. 25 years ago, all meetings were in the US, as were most of the participants. People came from Europe and Australia at significantly greater cost, but for the average attendee, putting all meetings in the US reduced meeting cost. It's now 25 years later, and that logic doesn't remotely start to work. From my perspective, the best we can do in that regard is place meetings somewhere that some of our participants come from and is less expensive than other choices for remote attendees - if we place the meeting far from everyone, it will cost more for the average attendee than if we at least put it near *someone* that is likely to attend.

Here's a thought for you. Folks have periodically proposed that all meetings happen at the large international airports, the hubs in the transportation system. That reduces transportation costs by putting the meeting somewhere that everyone can relatively-easily get to. What hotels do you find in those airports, what do they cost, and what do they offer? We could, for example, put the next IETF at Frankfurt Am Mein, and have everyone stay in the Sheraton Frankfurt - or not. We could all go to Narita, and try to hold a meeting in the $40 hotels near it - or not. It turns out that if you're trying to reduce cost, you go somewhere that isn't the hub of the transport network. That gives you a lot more options, and often options that you might actually prefer.

Something that *can* help there is to not require the hotel to be in/by the conference center. The "one roof" rule tends to mean that we select many-star hotels. Tell us that we can put the people in one place and the meeting somewhere else, and people can choose less-star hotels if they like.

Another issue relates to the conference center itself. We routinely have nine breakout sessions going at once, hold receptions, deliver coffee and cookies, and have meetings with 1000 people in a room. That means that we look for conference centers that can host those meetings. 25 years ago, the usual solution was for the host to donate the use of their own conference facilities (my wife still mentions the fact that we had a meeting at the University of Hawaii Honolulu and I spent an entire week in Hawaii indoors); when we became larger than 500 people and needed more than a handful of rooms at once, that got hard. Practical solutions that either reduce the room requirements or make for ways they can be donated might help. Go to the beach?

Oh, by the way, the conference cost is a deal, a horse-trade. If we meet in a conference center separate from hotel space, we can't offer the place room nights as a trade-off against meeting space, which means that both costs tend to go up.

I think something helpful to reduce the attendance fee would be to find a way to provide corporate sponsors to underwrite the cost. An issue we routinely have is that corporate sponsors want to be selling something, and the engineers that make a competitor's product aren't usually potential customers. Also, the companies that are likely to do so tend to have a number of attendees, and can do the math - sponsorships come out of a single budget, while attendance fees come out of departmental budgets, but the sum is the same. The companies that routinely help out one way or another also tend to feel that it's someone else's turn to be generous. Ideas there would be helpful.

So, here's something you can do that would actually help. Tell us how to reduce not the price of cookies or the price of the hotel room, but the price of the entire meeting as viewed by the average attendee.

---

From: John C Klensin <[email-masked]>
Date: Tue, 25 Oct 2011 17:48:07 -0400

--On Tuesday, October 25, 2011 10:19 -0700 Fred Baker
<[email-masked]> wrote:

> I think that a lot of people would like that. There are a
> number of problems that need to be solved to make them cheaper
> to attend.
> 
> One is the issue of air fare and hotel cost; these have been
> brought up before. 25 years ago, all meetings were in the US,
> as were most of the participants. People came from Europe and
> Australia at significantly greater cost, but for the average
> attendee, putting all meetings in the US reduced meeting cost.
> It's now 25 years later, and that logic doesn't remotely start
> to work. 
>...

Ok, Fred, let me enter one suggestion into this discussion that
would actually cut total costs, recognize and take advantage of
the observation that an increasing number of WGs are holding
virtual interim meetings, and reduce pressures on meeting time
conflicts and trying to get everything done in 4 3/4 days.

Eliminate one of the face to face meetings entirely -- go to two
a year and either hold the 4 3/4 day schedule or, better cut it
back to four.  Don't let any WG meet at those f2f meetings
unless it can demonstrate to the relevant AD that significant
progress has been made, via virtual interim meetings and posted
drafts, during the previous six months.  No interim meetings, no
drafts between full IETF meetings equals no meeting time (and a
lot of risk of being shut down as useless).

This wouldn't come for nothing.   We'd have to get much more
serious about interim meetings and adequate documentation and
tracking.  We've have to rethink our financial model (at least
the part ISOC doesn't cover) so that it didn't depend almost
entirely on getting the maximum number of people to travel to
f2f meetings three times a year.  We'd have to make a real
commitment to remote participation between full meetings --
possibly covered by the requirements and tools the RFP
contemplates, possibly not.   ADs would have to think very
carefully about what they need to watch and how... and about
adjusting the roles of WG Chairs they couldn't trust to do most
things without anyone looking over their shoulders.  Nomcom
schedules and many other things that depend on three full, f2f,
meetings a year would need to be reevaluated.

It is probably more change to our culture and how we do things
than anyone is actually willing to consider.  But the other way
to read your note --with which I almost entirely agree-- is
that, if one wants to see real savings, one has to change the
equation, not just diddle around with tuning some of the
parameters.  I continue to think we could do better with
location and cost tradeoffs, but probably not hugely better.
Simply reducing the number of times per year we need to have
large numbers of participants fly long distances, put them into
hotels and conference centers, etc., actually changes the
equation.

    john

---

From: Dave Cridland <[email-masked]>
Date: Wed, 26 Oct 2011 10:17:28 +0100

On Sun Oct 23 17:19:23 2011, Melinda Shore wrote:
>> mailing lists?
> working group chairs,

I'd add the cultural problem that no matter how many RFCs I author, I  
shall forever be barred from taking part in (for example) NomCom  
unless I show up to meetings in person.

While we instill a requirement to attend meetings to be a "real" IETF  
participant, we'll require people to attend meetings to do "real"  
participation.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 26 Oct 2011 09:38:00 -0600

On 10/25/11 3:48 PM, John C Klensin wrote:
> back to four.

Reducing the number of meetings a year from three to two makes sense.
Naturally, we'd need to work through the implications (e.g., the NomCom
schedule is defined in terms of three meetings a year).

Plus, it's a natural complement to having reduced the number of maturity
levels from three to two. ;-)

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 26 Oct 2011 12:17:43 -0400

Nothing happens without deadlines. I'd be more in favor of going back
to 4 meetings a year than going to 2...

Thanks,
Donald

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 26 Oct 2011 10:20:56 -0600

> to 4 meetings a year than going to 2...

Use virtual interim meetings (etc.) as a forcing function. There's more
than one way to set a deadline.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Oct 2011 19:28:25 +0200

Hi,

I don't have an opinion regarding the number of f2f meetings. But, as we've discussed before, I think we could make more out of the summer meetings (considering any e-mail etc activities taking place before and after them) by moving them away from the main summer vacation period.

So, no meetings in july and august.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Peter Saint-Andre [[email-masked]]
Sent: Wednesday, October 26, 2011 6:38 PM
To: John C Klensin
Cc: [email-masked]
Subject: Re: Requirement to go to meetings

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: "t.petch" <[email-masked]>
Date: Wed, 26 Oct 2011 18:28:46 +0200

----- Original Message -----
From: "John Leslie" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 25, 2011 5:06 PM
>    This is _not_ a good way to run a mailing-list!

You surprise me; I would say that many if not most of the IETF WG lists I track
run along those lines, with bursts of activity starting about the time the
cutoff for I-D submission is announced, and finishing soon after the I-D
submission window re-opens.  In between, we wait; sometimes it is for the chair,
but more often for the document 'editor' (and yes, I know that ADs are a
precious and scarce resource whose intervention should not be called on).

A technical fix would be to make it easier to change editor.  I strongly believe
that the IETF process, of change control of a WG I-D being vested in the WG, is
absolutely right and it goes wrong when either the creator of the individual
submission goes on regarding it as their own property, making changes without
waiting for list consensus on changes, or, more often, when they do not make
changes, in a timely manner, for which there is a consensus.

If the chair could say, without offending anyone, please incorporate these
changes within nn days, with the option, when that does not happen, to get
someone else to make them instead, then documents would come sooner and, IMO, be
of a higher quality.

Tom Petch

---

From: Fred Baker <[email-masked]>
Date: Wed, 26 Oct 2011 12:47:06 -0700

On Oct 26, 2011, at 8:38 AM, Peter Saint-Andre wrote:

> (e.g., the NomCom

no problem. We stop having the nomcom.

(he ducks)

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 26 Oct 2011 13:50:08 -0600

> no problem. We stop having the nomcom.

Sure, we just set up a (two-tier?) membership structure and have all the
members vote. Easy.

---

From: John Leslie <[email-masked]>
Date: Wed, 26 Oct 2011 16:31:52 -0400

t.petch <[email-masked]> wrote:
> You surprise me; I would say that many if not most of the IETF
> WG lists I track run along those lines, with bursts of activity
> starting about the time the cutoff for I-D submission is announced,
> and finishing soon after the I-D submission window re-opens.

   I won't dispute your data...

> In between, we wait; sometimes it is for the chair, but more often
> for the document 'editor'

   Yes, I see this a lot. :^(

   Sometimes it's worse: the document 'editor' doesn't meet the cutoff
and we wait for the next cutoff.

> (and yes, I know that ADs are a precious and scarce resource whose
> intervention should not be called on).

   Nonetheless they _do_ tackle such situations -- often it's recorded
in the Narrative Minutes without naming names...

> A technical fix would be to make it easier to change editor.

   Actually it's quite easy: if both WGCs agree, editors can be changed
for any reason at all, or even no reason in particular.

   The problem is, the new editors usually suffer the same symptoms.

> I strongly believe that the IETF process, of change control of a
> WG I-D being vested in the WG, is absolutely right

   +1

> and it goes wrong when either the creator of the individual
> submission goes on regarding it as their own property, making
> changes without waiting for list consensus on changes,

   Hmm... I see that a lot, too... It's not always bad, but it does
tend to slow the process.

> or, more often, when they do not make changes, in a timely manner,
> for which there is a consensus.

   I don't see as much of that -- of course most WGCs don't call
consensus quickly enough, in which case it's not exactly the
document editor's fault.

   IMHO, the happiest situations are where the document editor
responds to (almost) every suggestion, usually suggesting text for
how to clarify the point raised. Then the WGC calls consensus
when the comments die down.

   Alas, few WGCs choose document editors that will do this...

> If the chair could say, without offending anyone, please
> incorporate these changes within nn days, with the option,
> when that does not happen, to get someone else to make them
> instead, then documents would come sooner and, IMO, be
> of a higher quality.

   There ain't no such thing as "without offending anyone".
I suspect, however, that WGCs _could_ say something like that
privately and solicit what amounts to a resignation of the
document editor in question.

   The problem, IMHO, is that most WGCs have no idea how to
find someone to replace the document editor in question. My way
would be to announce the resignation; then say, "If nobody
volunteers to become document editor, we'll drop this from our
milestone list."

   WGCs, IMHO, take too many responsibilities on themselves; and
burnout too often follows. :^(

---

From: Mary Barnes <[email-masked]>
Date: Wed, 26 Oct 2011 15:52:01 -0500

> Sure, we just set up a (two-tier?) membership structure and have all the

[MB] You don't need a membership structure to have voting - you just allow
anyone that has attended the requisite number of meetings per the Nomcom
process to vote - i.e., if you are qualified to be a voting member of the
Nomcom, you can vote.    I personally believe that voting would be better
than the current model.  As it is, a very small percentage of the
participants actually contribute to the process in the form of nominating or
providing feedback:
http://tools.ietf.org/html/draft-barnes-nomcom-report-2009-00 (section 6.2)

So, making it easier to provide input in the form of a vote might actually
get more folks caring about who the leaders are.    It would also save a
tremendous amount of work on the part of the folks that serve on the Nomcom.
 [/MB]

[Also, ducking]

Mary.

---

From: Ross Callon <[email-masked]>
Date: Wed, 26 Oct 2011 23:00:24 -0400

Mary;

Would you want the comments that are currently sent in privately to nomcom to become public, or do you want the voters to make their choices without hearing these comments?

Ross

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: Wednesday, October 26, 2011 4:52 PM
To: Peter Saint-Andre
Cc: John C Klensin; [email-masked]
Subject: Re: Requirement to go to meetings

On Wed, Oct 26, 2011 at 2:50 PM, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>> wrote:

[MB] You don't need a membership structure to have voting - you just allow anyone that has attended the requisite number of meetings per the Nomcom process to vote - i.e., if you are qualified to be a voting member of the Nomcom, you can vote.    I personally believe that voting would be better than the current model.  As it is, a very small percentage of the participants actually contribute to the process in the form of nominating or providing feedback:
http://tools.ietf.org/html/draft-barnes-nomcom-report-2009-00 (section 6.2)

So, making it easier to provide input in the form of a vote might actually get more folks caring about who the leaders are.    It would also save a tremendous amount of work on the part of the folks that serve on the Nomcom.  [/MB]

[Also, ducking]

Mary.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 27 Oct 2011 05:20:21 +0200

On 10/27/2011 5:00 AM, Ross Callon wrote:
> Mary;
>
> Would you want the comments that are currently sent in privately to nomcom to
> become public, or do you want the voters to make their choices without hearing
> these comments?

The general implication of Ross's question comes from the entirely predictable 
fact that most folk in the IETF are not all that involved with more than a 
narrow range of other folk and do not know much about IETF management, or even 
that much about process.

Nomcom creates a small group of folk who spend a great deal of time getting 
much, much more familiar with people, tasks, requirements and process.  It does 
this at massive effort cost to those doing the actual work, of course, and it 
certainly would be nice to find ways to reduce that work.  (My own preference 
continues to be to ensure that a portion of Nomcom voting members has direct 
experience doing IETF management tasks, producing RFCs and equivalent, deeper 
involvement in the IETF; that is, ensuring that the voting members are 
guaranteed a base level of knowledge about the IETF.)

I'm hard-pressed to see how an IETF-wide voting mechanism will produce better 
results than the current Nomcom process.  It would be a simpler, less stressful 
process, but it would also be less informed.

d/

-- 

   Dave Crocker

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Oct 2011 16:24:53 +1300

It's really annoying when a thread drifts to a wildly different topic
without somebody thinking to change the Subject header.

My comments on nominees would be much less frank if I knew they
would be published. In fact, I doubt if I would make any at all.

Here's a comment I sent in a number of years ago.

"Arrogant, sometimes rude, not interested in listening to other
people. I think <pronoun> would be an abysmal AD."

In public? I don't think so. The whole idea of honest feedback only
works when kept confidential.

As for voting, I understand Mary's frustration at the lack of
participation, but this really must not become a popularity
contest and certainly not be put at risk of capture by companies
or countries that send a lot of people to meetings. After all,
this thread started out about how to *not* need to go to meetings.

Regards
   Brian

On 2011-10-27 16:00, Ross Callon wrote:
> ------------------------------------------------------------------------
>

---

From: Melinda Shore <[email-masked]>
Date: Wed, 26 Oct 2011 19:30:57 -0800

On 10/26/11 7:20 PM, Dave CROCKER wrote:
> I'm hard-pressed to see how an IETF-wide voting mechanism will produce
> better results than the current Nomcom process. It would be a simpler,
> less stressful process, but it would also be less informed.

Feh.  This one's easy: vote for the individual who'd sponsor your
individual submission.

Works great, right?

Melinda

---

From: Martin Sustrik <[email-masked]>
Date: Thu, 27 Oct 2011 07:42:50 +0200

On 10/24/2011 07:16 PM, SM wrote:

> follow the BoF you are interested in. There may be times when decisions
> are taken during a meeting. It is not worth the nit-picking if the
> outcome won't change.

As BoFs are held in early stages of development, there's unlikely to be 
much funding for it, no budgets approved yet etc. So, at the BoF 
there'll be couple of experts who managed to get the funding and random 
selection of IETF folks who drop in just because they happen to be around.

That can be either bad thing (too few experts, no good estimate about 
participation in the potential working group) or a good thing (random 
selection of IETF participants tests the sanity of the proposal).

In the former case it would be better to hold BoFs via conference calls 
or similar means. In the latter case the existing model works OK.

For example: We have a discussion group of ~50 people that we would like 
to change to IETF WG, however, it's not likely more than 2-3 people 
would be able to get to the BoF in person.

Martin

---

From: Bob Hinden <[email-masked]>
Date: Thu, 27 Oct 2011 08:29:16 +0200

+1

Bob

---

From: SM <[email-masked]>
Date: Thu, 27 Oct 2011 01:54:15 -0700

Hi Martin,
At 22:42 26-10-2011, Martin Sustrik wrote:
>That can be either bad thing (too few experts, no good estimate 
>about participation in the potential working group) or a good thing 
>(random selection of IETF participants tests the sanity of the proposal).

The second point is quite interesting.  It may also be applicable for 
individual submissions.  That random selection brings in participants 
from outside the area if it is an in-person meeting.

>For example: We have a discussion group of ~50 people that we would 
>like to change to IETF WG, however, it's not likely more than 2-3 
>people would be able to get to the BoF in person.

There isn't any requirement for a BoF to form a WG.  BTW, there is a 
difference between "discussion group of ~50 people" and "~50 
subscribers".  The former means broader participation and might 
provide a better view of commitment in comparison to room filled with 
people who only have to be around for an hour.

There was a comment in this thread about "without offending 
anyone".  As an example, someone on another mailing list used the 
word "rubbish" in a reply [1].  In a face to face meeting, someone 
used the following words: "one of the worst pieces of [removed] I 
ever read in my life" [2].  Would the discussion group interacting 
only remotely be able to handle the social hurdles?

Regards,
-sm

1. I didn't read the exchange as negative.
2. The follow-up was positive.

---

From: Mary Barnes <[email-masked]>
Date: Thu, 27 Oct 2011 08:38:30 -0500

On Wed, Oct 26, 2011 at 10:00 PM, Ross Callon <[email-masked]> wrote:

> Mary;****
>
> ** **
>
> Would you want the comments that are currently sent in privately to nomcom
> to become public, or do you want the voters to make their choices without
> hearing these comments? ****
>
> ** **
>
> Ross
>

[MB] No, I do not think the comments should be public.  My point was that
there is such a small percentage of the community that even provides input
that it is really difficult to make really good decisions with that
information.  Each nomcom asks for detailed feedback, but it is rare to get
feedback that provides concrete examples of why person x is the best choice
for a position.  That makes the job of the Nomcom extremely difficult and is
one of the reasons why the decisions can be far from perfect.

The primary problem with the current Nomcom model that can't be fixed by a
process change is the lack of community input (Note: there is still time for
folks to provide that input for this year's Nomcom!!!)  So, I consider
voting to be an easy way for folks to express an opinion without providing
details - it at least could hopefully broaden community participation
because it takes far less effort.

[/MB]

Regards,
Mary.

****

---

From: Fred Baker <[email-masked]>
Date: Thu, 27 Oct 2011 08:01:14 -0600

On Oct 27, 2011, at 2:54 AM, SM wrote:

> There isn't any requirement for a BoF to form a WG.

I think you're saying that there shouldn't be; at this instant, there actually is such a requirement. What there isn't a requirement for is a Bar BOF (and I would argue that there *is* a requirement that if a Bar BOF be held, it be held in a bar :-)

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 27 Oct 2011 10:03:42 -0400

Hi Fred,

> I think you're saying that there shouldn't be; at this instant, there actually is such a requirement. What there isn't a requirement for is a Bar BOF (and I would argue that there *is* a requiremen…

Actually, there isn't, technically, a requirement for a BOF to form a WG.  It is so often done that we think of a BOF as a necessary step, but the standards BCPs don't require one and, in fact, the PCP WG was recently formed without at BOF.

Margaret

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 27 Oct 2011 16:14:59 +0200

On 10/27/2011 4:03 PM, Margaret Wasserman wrote:
>> I think you're saying that there shouldn't be; at this instant, there
>> actually is such a requirement.
...
> Actually, there isn't, technically, a requirement for a BOF to form a WG.  It
> is so often done that we think of a BOF as a necessary step, but the
> standards BCPs don't require one and, in fact, the PCP WG was recently formed
> without at BOF.

The IESG periodically imposes a higher bar to process than formal rules require.

My impression is that it /is/ sometimes possible to form a wg without having a
BOF but that the IESG treats the case with skepticism and hence it is strongly
discouraged by the cognizant AD who is shepherding the nascent working group
leaders.

d/

-- 

   Dave Crocker

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Oct 2011 07:42:28 -0700

On Oct 27, 2011, at 7:01 AM, Fred Baker wrote:

> I think you're saying that there shouldn't be; at this instant, there actually is such a requirement.

Either you are incorrect, or the new MILE WG was chartered incorrectly. I'm hoping it is the former.

> What there isn't a requirement for is a Bar BOF (and I would argue that there *is* a requirement that if a Bar BOF be held, it be held in a bar :-)

The MILE BarBoF in Quebec was certainly not in a bar. Further, the organizers went out of their way to encourage remote participation, and there was a presentation by phone of someone who had some interesting use scenarios that were put into the eventual charter. (Funny how this ties to the message that started this thread bak two or three levels of indirection.)

--Paul Hoffman

---

From: John C Klensin <[email-masked]>
Date: Thu, 27 Oct 2011 11:25:54 -0400

Subject changed, this is about to go off in a different
direction.

--On Thursday, October 27, 2011 08:38 -0500 Mary Barnes
<[email-masked]> wrote:

>...
> [MB] No, I do not think the comments should be public.  My
> point was that there is such a small percentage of the
> community that even provides input that it is really difficult
> to make really good decisions with that information.  Each
> nomcom asks for detailed feedback, but it is rare to get
> feedback that provides concrete examples of why person x is
> the best choice for a position.  That makes the job of the
> Nomcom extremely difficult and is one of the reasons why the
> decisions can be far from perfect.
> 
> The primary problem with the current Nomcom model that can't
> be fixed by a process change is the lack of community input
> (Note: there is still time for folks to provide that input for
> this year's Nomcom!!!)  So, I consider voting to be an easy
> way for folks to express an opinion without providing details
> - it at least could hopefully broaden community participation

Mary,

Please understand that what I'm about to say is not a criticism
of any hard-working Nomcom or its members, present or past.

First, the problem with voting in our environment is ensuring
fairness: if nothing else, it would be really easy for a company
who felt like doing so to pack the proverbial ballot box.

But, more important, when the Nomcom model was developed, I
think the assumption of most of the community would be that the
Nomcom would be populated mostly by really active participants
in the IETF and that, in general, if a particular candidate
wasn't personally known to at least several Nomcom members, that
would be a really bad sign about that candidate.  In that
environment, extensive polls/ questionnaires were probably
unnecessary; at worst, Nomcom's didn't need to depend on them as
a primary source of information.

Since then, several things have happened.  The most important is
that the community has gotten bigger and a number of trends have
combined with size to make the assumption of first-person
knowledge a lot less likely.  The number of positions to be
filled has also increased significantly: for example, I'm pretty
sure there were fewer areas in 1996 and the typical area had one
AD, rather than two being the norm for everyone by the IETF
Chair.  The Nomcom process has gotten longer (probably in part
as a result) and serving on a Nomcom has become more burdensome.
With most positions to be filled by the Nomcom, effectively
having a rule that anyone interested in any of those positions
should not volunteer to serve on the Nomcom may have some effect
on participation.   I'm sure you could add to that list.

For that set of reasons, while I don't think voting is the
answer unless we decide to change our membership model so that
we can identify close affiliates and vote by organization and/or
restrict the ability of any organization or group of
organizations to capture the process --and, for the record, I
don't favor trying that -- I do think some fundamental
rethinking of the Nomcom model may be important and important
soon.

In the interim, if the Nomcom wants more feedback, I suggest
that some tuning (not requiring major reforms) may be in order
to actually make giving that input easier.  Let me give four
examples, but they are only examples.  There may be others that
would be even more useful to think about.

(1) There is an incumbent bias built into the system because
Nomcoms (using a reasonable reading of the criteria in various
BCPs), appear to believe that their job is to return an
incumbent who is willing to serve again unless a candidate is
available who would be clearly superior.  Especially for the
IESG, unless the incumbent has screwed up in a serious way, that
bar will normally be impossibly high because a sitting AD is a
known quantity and almost any alternate candidate is a risk.
Spencer Dawkins and I made a proposal a couple of years ago for
the Nomcom to review the incumbents who were willing to serve
again separately, make decisions about them, and only then start
considering others.  The proposal, at least in the last version
posted
(https://datatracker.ietf.org/doc/draft-klensin-nomcom-incumbents-first/)
never got an real traction.  The proposal had some
disadvantages, some of which might have been fixed with more
work, and others of which were just tradeoffs to be considered.
But one clear effect would have been to drastically reduce the
number of positions for which the community is asked to comment
on a list of candidates.

(2) Independent of that particular suggestion, the number of
slots on which people are now being asked to comment, and, in
some cases, the number of people who are listed for each slot,
is just daunting.  Ask someone to comment on two or three
candidates for one position (or even a few positions) and you
will probably get a lot of input, especially if the people you
ask seem to be a focused list, chosen in some intelligent way.
Ask folks to comment on 48 names and I suggest that human nature
predicts a lot of "maybe I'll get to that another time" and
general tuning out.  

Perhaps it means that RFC 5680 was the wrong answer to the
question/ problem, but I suggest that there is a reason why no
plausible search process in the work world presents a final
selection process with 48 people, or even seven, for in-depth
consideration and comments.  Developing short lists has the
advantage that the selection process gets comments on those
candidates for whom it really wants and needs comments _and_
people have more incentive to write good comments for the
smaller number of people for whom they will be useful.  Listing
everyone who expressed interest (or was willing to be listed for
some other reason) might get a Nomcom to look again at a
superstar who had slipped through the cracks of earlier
considerations but is much more likely to just overwhelm the
system with noise. 

(3) I don't believe it has happened this year, but trends in the
community predict that, sooner or later, we will have someone
volunteer for a large number of positions simply because he or
she (or whomever they work for) wants them in the IETF
leadership.   Someone ought to be able to write one comment that
says "Goofy wants to be in the leadership to enhance his resume
and told several of us that at a Bar BOF and should not be
selected for _any_ position.  If you don't believe me alone,
check with X, Y, or Z."  In the current model, that would
require writing a separate review for each position.  Lots of
make-work; might not happen at all.   But a Nomcom would really
want that input I think.

(4) I have some basis for believing I can comment on the IAB and
its needs.  Perhaps I'm completely wrong, too old and set in my
ways and that my opinions should be dismissed or negatively
weighted -- that is the Nomcom's decision, not mine.  But one of
my observations is that the IAB's role is not really very well
defined for Nomcom considerations and that the role and utility
of the IAB is strongly shaped by those who are put on it.  In
the interest of full disclosure, if I were [re]inventing the
world, I would significantly reduce the fraction of the IAB that
is appointed by the Nomcom, but that is another discussion.
IMO, the way for me to make useful comments is to explain some
scenarios about what I think the IAB might be like and then tell
the Nomcom which people I would select to advance each of those
scenarios.   With a very small number of exceptions, I can't
evaluate people without those scenarios; simply presenting me
with a list of 20 choices creates high odds of the Nomcom's
getting no comments at all.

Just my opinion, YMMD.

   john

---

From: Fred Baker <[email-masked]>
Date: Thu, 27 Oct 2011 09:31:52 -0600

Sounds like I made an error...

---

From: Ross Callon <[email-masked]>
Date: Thu, 27 Oct 2011 11:45:58 -0400

I very much agree that community input is required for nomcom to make good choices. There is no way that any one nomcom member could possibly know every candidate for every position.

And yes, right now is the time to give input.

Thanks, Ross

From: Mary Barnes [mailto:[email-masked]]
Sent: Thursday, October 27, 2011 9:39 AM
To: Ross Callon
Cc: Peter Saint-Andre; John C Klensin; [email-masked]
Subject: Re: Requirement to go to meetings

On Wed, Oct 26, 2011 at 10:00 PM, Ross Callon <[email-masked]<mailto:[email-masked]>> wrote:
Mary;

Ross

[MB] No, I do not think the comments should be public.  My point was that there is such a small percentage of the community that even provides input that it is really difficult to make really good decisions with that information.  Each nomcom asks for detailed feedback, but it is rare to get feedback that provides concrete examples of why person x is the best choice for a position.  That makes the job of the Nomcom extremely difficult and is one of the reasons why the decisions can be far from perfect.

The primary problem with the current Nomcom model that can't be fixed by a process change is the lack of community input (Note: there is still time for folks to provide that input for this year's Nomcom!!!)  So, I consider voting to be an easy way for folks to express an opinion without providing details - it at least could hopefully broaden community participation because it takes far less effort.

[/MB]

Regards,
Mary.

---

From: Randy Bush <[email-masked]>
Date: Thu, 27 Oct 2011 08:55:32 -0700

> this thread started out about how to *not* need to go to meetings.

<aol>

---

From: SM <[email-masked]>
Date: Thu, 27 Oct 2011 05:09:21 -0700

>would be published. In fact, I doubt if I would make any at all.

It is safer not to leave any compromising evidence.

>Feh.  This one's easy: vote for the individual who'd sponsor your

Absolutely. :-)

This year's NomCom has members from:

North America          5
  Cisco.com        2
  Juniper.net      2
  Avaya.com        1

Europe                 2
  Nokia.com        1
  NLnetlabs.nl     1

Asia                   3
  Huawei.com       2
  Chinamobile.com  1

Cisco.com, juniper.net, huawei.com and nokia.com are in the top 10 
for authorship affiliation.  The above is also a refection of 
regional attendance.  A person who is not aware of the peculiarities 
(see RFC 3797) of NomCom might have a different reading of the above.

>non-attending active participants.

That could be interpreted as "let's listen what others have to 
say".  I would extend that to non-active participants.

The following is off-topic.  NomCom is currently requesting comments 
about the persons who have volunteered (or have been nominated) for 
IAB or IESG positions.  As the names have not been publicly 
disclosed, I prefer not to list them.

There is currently a discussion [1] about whether a draft should be 
published as an Applicability Statement or a Best Current 
Practice.  I would be grateful if the nominees could share their 
views about the publication path.

IAOC nominees might find it easier to share their views about the following:

    No food or beverages are allowed to be brought into the meeting rooms and
    working group sessions unless specifically served by the IETF.

Regards,
-sm

1. http://www.imc.org/ietf-smtp/mail-archive/msg06842.html

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Oct 2011 12:30:04 -0400

--On Wednesday, October 26, 2011 12:17 -0400 Donald Eastlake
<[email-masked]> wrote:

> Nothing happens without deadlines. I'd be more in favor of
> going back to 4 meetings a year than going to 2...

That is why I didn't suggest "going to 2" but dropping the f2f
count to two _and_ insisting that WGs hold interim virtual
meetings.  Those meetings would, given competent management,
impose deadlines too.  And, if you read my (admitted sketchy)
suggestion, you would note that it essentially forces each WG
into four meetings a year if it wants to meet f2f twice.

So, if you want to look at it that way, for WGs, it is a
proposal to change three f2f meetings a year to four meetings a
year, but with only two of them f2f.

As others have pointed out, that doesn't solve the "water
cooler" problem.  It would probably require some rethinking of
how we handle BOFs, WG creation, and other tasks.  But the
question, IMO, is whether we really need three f2f full meetings
a year to manage those things or whether we could get clever
enough to deal with only two of them.

   john

---

From: Richard Kulawiec <[email-masked]>
Date: Thu, 27 Oct 2011 07:03:38 -0400

On Tue, Oct 25, 2011 at 05:48:07PM -0400, John C Klensin wrote:
> back to four.  [snip]

I support this concept, although I would go much further and
eliminate ALL face-to-face meetings.

Travel (for meetings) is expensive, time-consuming, energy-inefficient,
and increasingly difficult.  As a group that possesses significant
'net expertise, we should have long since figured out how to organize
our processes so that it's not necessary, thereby removing significant
barriers to participation and saving everyone's time and money.

Yes, that means not just working through the technology issues, but
the procedural ones as well -- and that latter may be difficult than
the former.  But I think it's feasible, and I think we should commit
to it, with a goal of eliminating all meetings by 2014.

---rsk

---

From: Dave Cridland <[email-masked]>
Date: Fri, 28 Oct 2011 10:03:48 +0100

On Wed Oct 26 17:30:04 2011, John C Klensin wrote:
> how we handle BOFs, WG creation, and other tasks.

Creating a virtual water cooler is possible - XMPP chatrooms do  
provide this pretty well - but there's a cultural shift required that  
requires effort to put into place.

I think we could probably get this going to some degree if we [for  
any value of we] simply stated that we'd hang about in the relevent  
chatrooms. For me (being a woolly apps kind of guy) that'd presumably  
be [email-masked] and [email-masked] - I note  
there's even people in the latter.

Any reasonable XMPP client will include support for automatically  
joining chatrooms. For anyone here interested, it's "Bookmarks" -  
XEP-0048, typically stored in XEP-0049, for which you'll need  
server-side support - GTalk won't quite cut it, I'm afraid.

These things need a critical mass - a solid group of regulars in the  
chatroom who're willing to basically hang around and chat - but it's  
possible, and - I think - worthwhile whatever we do. So I've just  
bookmarked said rooms with auto-join to see what happens.

Dave.

---

From: Ray Bellis <[email-masked]>
Date: Fri, 28 Oct 2011 10:38:15 +0000

> eliminate ALL face-to-face meetings.

I absolutely wouldn't.

> and increasingly difficult.

Your assertions above are all true, but that does not mean that people should be denied the opportunity to meet.

Being mostly social animals, I believe it's essential that we *do* get to actually meet our IETF colleagues.

Do not underestimate how important it is to actually establish a rapport with other people, and that can really only be achieved face-to-face.  This is simple psychology.  You simply can't get to know people and work with them effectively if all they are is faceless email accounts or a voice on a crowded conf call.

I've met loads of people at my four years of IETF, and many of those I now consider friends.  I know what their competences are, and I know which ones I trust and distrust.  You just don't get that from remote participation.

Ray

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 28 Oct 2011 07:32:57 -0400

+1

Donald

On Friday, October 28, 2011, Ray Bellis <[email-masked]> wrote:
> Your assertions above are all true, but that does not mean that people
should be denied the opportunity to meet.
> Do not underestimate how important it is to actually establish a rapport
with other people, and that can really only be achieved face-to-face.  This
is simple psychology.  You simply can't get to know people and work with
them effectively if all they are is faceless email accounts or a voice on a
crowded conf call.
>
> I've met loads of people at my four years of IETF, and many of those I now
consider friends.  I know what their competences are, and I know which ones
I trust and distrust.  You just don't get that from remote participation.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 28 Oct 2011 10:48:50 -0400

Cool idea.  I would hang out if other people did.

+1 to using protocols other than email for ephemeral discussions such as these :)  

--Richard

On Oct 28, 2011, at 5:03 AM, Dave Cridland wrote:

> Creating a virtual water cooler is possible - XMPP chatrooms do provide this pretty well - but there's a cultural shift required that requires effort to put into place.
> 
> I think we could probably get this going to some degree if we [for any value of we] simply stated that we'd hang about in the relevent chatrooms. For me (being a woolly apps kind of guy) that'd presumably be [email-masked] and [email-masked] - I note there's even people in the latter.
> 
> Any reasonable XMPP client will include support for automatically joining chatrooms. For anyone here interested, it's "Bookmarks" - XEP-0048, typically stored in XEP-0049, for which you'll need server-side support - GTalk won't quite cut it, I'm afraid.
> 
> These things need a critical mass - a solid group of regulars in the chatroom who're willing to basically hang around and chat - but it's possible, and - I think - worthwhile whatever we do. So I've just bookmarked said rooms with auto-join to see what happens.
> 
> Dave.
> --

---

From: Dave Cridland <[email-masked]>
Date: Fri, 28 Oct 2011 16:54:41 +0100

> Cool idea.  I would hang out if other people did.

There are 5 people in [email-masked] now. Hardly a critical  
mass, but it may be sufficient to count as "other people", at least.

> +1 to using protocols other than email for ephemeral discussions  

For it to take over as the discussion venue of first resort, you  
really need a situation where mentioning something in the chatroom  
makes you feel like you've adequately vented. That implies you need  
not only a reasonable number of people, but the kind of people you  
wanted to raise the issue in front of.

Of course, we could even discuss this in [email-masked] now.

Dave.

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 28 Oct 2011 14:10:52 -0400

Hi SM,

> This year's NomCom has members from:

The correct numbers are

North America: 3
Europe: 4
Asia: 3

In the nomcom case, the members with the cisco.com addresses are from
Europe. :-)

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 28 Oct 2011 14:32:23 -0400

Hi John,
  Just responding to one specific concern (No. 3) you raised. I do
believe that the other 3 (Nos. 1, 2 and 4) require process changes that
cannot take place during the current nomcom cycle.

On 11-10-27 11:25 AM, John C Klensin wrote:
> ...snipped...

You can already do this today. Just enter your feedback about the
nominee into *any* one of the positions and state that it is for all the
positions. The tool does not handle this case, but the humans behind
certainly do.

Thanks
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Oct 2011 10:50:40 +1300

There's a reason we use email here. It's called time zones.
Jabber doesn't work when people are spread across all time
zones.

There are forum-style mechanisms that also avoid the time zone
problem, but I've never found them as convenient as threaded
email.

 Brian (Saturday morning, 10:50 a.m)

On 2011-10-29 04:54, Dave Cridland wrote:
> For it to take over as the discussion venue of first resort, you really
> need a situation where mentioning something in the chatroom makes you
> feel like you've adequately vented. That implies you need not only a
> reasonable number of people, but the kind of people you wanted to raise
> the issue in front of.
>

---

From: Dave Cridland <[email-masked]>
Date: Mon, 31 Oct 2011 10:18:38 +0000

> problem, but I've never found them as convenient as threaded

Thank you, I had absolutely no idea that people didn't all come  
online throughout the world at precisely the same time. You know,  
this probably has an impact on various large-scale global services.

You'll note I have *not* said that we shouldn't use the mailing  
lists; I have said (and continue to maintain) that real-time  
chatrooms also have a place. Firstly, it's relatively commonplace to  
have some reasonable overlap between various groups of people - I'd  
even typically have at least an hour or two overlap with you, and you  
were (last Friday) 12 hours offset from me.

On top of that, chatroom setups used for continuous occupancy  
typically have a history which is replayed to new occupants when they  
join - XMPP does this too, and this can be sufficient for low-grade  
non-real-time communications. That said, I think our existing  
chatrooms are configured not to have history - presumably to avoid  
confusing when they're only used for three single weeks throughout  
the year.

Dave.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Nov 2011 09:07:54 +1300

On 2011-10-31 23:18, Dave Cridland wrote:

> That said, I think our existing chatrooms are configured not to have history - presumably to avoid confusing when they're only used for three single weeks throughout the year. 

Indeed. This is a major annoyance when joining a session late or catching only
the second session of a 2-session WG. Also it is very annoying when one gets dropped
from a jabber session and has to rejoin.

I think all the rooms at jabber.ietf.org should have history enabled, but cleared
out just prior to each meeting.

   Brian

---

From: Doug Barton <[email-masked]>
Date: Mon, 31 Oct 2011 13:20:36 -0700

+1

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Dave Cridland <[email-masked]>
Date: Mon, 31 Oct 2011 20:23:07 +0000

On Mon Oct 31 20:07:54 2011, Brian E Carpenter wrote:
> > That said, I think our existing chatrooms are configured not to  
> have history - presumably to avoid confusing when they're only used  
> for three single weeks throughout the year.
> 
Indeed, I've run foul of this on a few occasions.

> out just prior to each meeting.

Well, history clearing is not a standard feature (it's in our  
implementation but I think we may be unique there).

On the other hand, there are standard ways [XEP-0045 §7.1.16] for  
clients to request that they only get relatively recent history, such  
as the previous week at maximum - or the last time they were in the  
room, indeed - which makes the "three month old history" problem  
entirely soluble with a decent client.

Dave.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Nov 2011 10:11:49 +1300

Scott,

Yes, of course you are right.

   Brian

On 2011-11-01 10:00, Scott O. Bradner wrote:
> the audio of sessions is recorded & (I assume) not destroyed before the next meeting - why should the 
> jabber record be secret (by the process of removal) - why not dump the old logs in a place that
> people can find them later
> 
> Scott
> 
> On Oct 31, 2011, at 4:20 PM, Doug Barton wrote:
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 31 Oct 2011 14:14:39 -0700

In XMPP chatrooms, there are two separate things:

1. Room history. This is the messages that show up in your IM client
when you join the room.

2. Chat logs. These are archived to a website somewhere and live there
forever.

In this conversation, we're talking about room history, not chat logs.