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: "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: 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 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: 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: 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: 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: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Oct 2011 16:38:41 -0400

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

Are you imagining that we will get a remote participation service that 
can deliver cookies (the edible, not browser, kind) to remote participants?

If not, then the remote participants won't get comparable services and 
shouldn't get comparable costs.

There are real costs attributable to physical meetings, and to 
supporting remote participation. And then there is a part of the meeting 
fee that goes to supporting the organization in general.

If those can be well characterized then it should be possible to come up 
with a fee schedule for local and remote participation. Likely they 
won't be the same.

	Thanks,
	Paul

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Oct 2011 13:59:46 -0700

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

Some costs do differ at first glance:
	- remotes can't eat cookies or drink coffee
	- locals don't need remote A/V feeds
	- locals don't need camera staff

It's not that simple, though:
- would remotes participate if there were no locals?
they maybe they benefit from providing cookies/coffee too
- would locals participate as well if there were no remotes?
then maybe they benefit from the feeds/camera staff too

There are other costs are shared:
	- support for ISOC
	- room costs
	
This is all very complex to analyze, but somewhat irrelevant, IMO.

Cost != price.

The price can be set based on social engineering goals, e.g., to make it 
less attractive to participate remotely given the indirect cost of local 
participation (flights/hotels), or to make it more attractive to offset 
the cost of not being in the same timezone.

Right now, we set remote participation cost at zero to encourage it 
where possible, given the existing disincentive (timezone difference, 
less effective participation, lack of hallway chat abilitY), and to 
encourage "have nots".

Overall, though, I believe that price is what's being debated, not cost.

Joe

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 20 Oct 2011 17:01:45 -0400

> can deliver cookies (the edible, not browser, kind) to remote participants?

Please. can we have that?  I haven't been able to attend nearly as many
meetings as in the past, and I miss the cookies. :-)

---

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: 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
 
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Oct 2011 19:54:51 -0400

I totally agree that price != cost.
But cost is typically a *factor* in determining the price.
I was replying to a message that seemed to assert that the price should 
be the same for local and remote participation. Its possible that after 
understanding the costs it is decided that the price should be the same. 
But if the costs are vastly different then there is a good chance that 
the prices will be different too.

	Thanks,
	Paul

---

From: Henk Uijterwaal <[email-masked]>
Date: Fri, 21 Oct 2011 09:07:49 +0200

> meetings as in the past, and I miss the cookies. :-)

There is cookies.com which will deliver cookies to your desk.

Seriously: I think that there is a requirement here that we can limit
limit access to the RPS to people who pay an entry fee.  What that fee
is and what exactly it covers, is a matter of policy and can be discussed
much later.

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: 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: 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: Eric Burger <[email-masked]>
Date: Fri, 21 Oct 2011 15:43:51 +0000

If we can avoid it, I would rather use this Internet thing and enable all comers to participate in the IETF.  We cannot complain about not having enough active document editors on the one hand and then bar new people from participating.

---

From: Acee Lindem <[email-masked]>
Date: Fri, 21 Oct 2011 11:58:46 -0400

On Oct 21, 2011, at 11:43 AM, Eric Burger wrote:

> If we can avoid it, I would rather use this Internet thing and enable all comers to participate in the IETF.

I think this statement falls into the "be careful what you wish for category". 

>  We cannot complain about not having enough active document editors on the one hand and then bar new people from participating.

We're not barring new people - we're simply amortizing the cost of the meeting over all attendees. Why should the people who attend in person subsidize those who attend remotely? 
Additionally, when you consider the cost of the time and travel, the $650 registration fee is insignificant. 

Acee

---

From: Eric Burger <[email-masked]>
Date: Fri, 21 Oct 2011 16:03:13 +0000

Just because I feel like arguing, how about this:

ALL IETF work is done on email lists. Why should I *encourage* people to meet in person and not get work done on mail lists by subsidizing their having a face-to-face meeting that I cannot attend?

---

From: Leif Johansson <[email-masked]>
Date: Fri, 21 Oct 2011 18:05:11 +0200

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

+1

I also humbly request help with tagging this discussion for sorting
purposes.

---

From: Mary Barnes <[email-masked]>
Date: Fri, 21 Oct 2011 11:10:10 -0500

A couple comments below [MB].

Mary.

> I think this statement falls into the "be careful what you wish for

[MB] I seriously doubt that you will get an overwhelming number of people
that participate remotely that this would be an issue. Also, you need to
consider that people that are attending the f2f also take advantage of
Meetecho while they are at the meeting.  More importantly the tool provides
both remote participation *and* it provides a playback for folks that are at
the meeting in preparing meeting notes, clarifying individual action items,
etc.  [/MB]

>  We cannot complain about not having enough active document editors on the
one hand and then bar new people from participating.

We're not barring new people - we're simply amortizing the cost of the
> meeting over all attendees. Why should the people who attend in person
> subsidize those who attend remotely?

[MB] If you think this is a valid concern, then you also need to consider
that those of us who don't eat cookies (or can't eat the cookies or eat less
food than others) are subsidizing those who eat lots of cookies.  So, if you
want to charge people for remote participation, then you should be charging
for the cookies.  [/MB]

Additionally, when you consider the cost of the time and travel, the $650
registration fee is insignificant.

Acee

---

From: Joel jaeggli <[email-masked]>
Date: Fri, 21 Oct 2011 09:23:10 -0700

On 10/21/11 08:58 , Acee Lindem wrote:
>> If we can avoid it, I would rather use this Internet thing and
>> enable all comers to participate in the IETF.
> 
>> We cannot complain about not having enough active document editors
>> on the one hand and then bar new people from participating.
> 
> We're not barring new people - we're simply amortizing the cost of
> the meeting over all attendees. Why should the people who attend in
> person subsidize those who attend remotely? Additionally, when you
> consider the cost of the time and travel, the $650 registration fee
> is insignificant.

one of the things to measure is simply the number of remote particapants
and the level of concurrency.

having done this is in the past (becuse I run the audio stream) there
are rather few participants who attend a lot of meetings (within the
course of an ietf week) remotely, short of a remote area director.

so for a given meeting slot (say monday at 9am) there might be between
40-100 total remote participants. that's roughly 10% of the number of
participants as are present onsite.

so one thing to tease out is are (or really how are) remote attendance
patterns different than those of present one... timezone offset for a
given meeting vs the bulk of the remote particpants is a big issue.

>>>>> Are you imagining that we will get a remote participation
>>>>> service that can deliver cookies (the edible, not browser,
>>>>> kind) to remote participants?
>>>> 
>>>> Please. can we have that?  I haven't been able to attend nearly
>>>> as many meetings as in the past, and I miss the cookies. :-)
>>> 
>>> Seriously: I think that there is a requirement here that we can
>>> limit limit access to the RPS to people who pay an entry fee.
>>> What that fee is and what exactly it covers, is a matter of
>>> policy and can be discussed much later.
>>> 
>>> Henk
>>> 
>>> -- 
>>> http://www.uijterwaal.nl Phone: +31.6.55861746

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 22 Oct 2011 03:28:27 +0900

> the meeting in preparing meeting notes, clarifying individual action items,

And there are people who attend one WG meeting and use remote 
participant tools to listen/watch into another meeting. Should they pay 
twice ?-).

I personally wouldn't mind paying something for remote participation if 
it's in a reasonable range (because I have some budget I can use for 
that but not for travel abroad).

In general, I can't see it being the same, because what you get is much 
less (the main thing missing being the hallway stuff, and the 
possibility to grab a mike or to just talk loudly and nobody being able 
to cut you off).

Also, if you think about a company where a manager needs to approve 
stuff, there's some tiny merit in an argument like: If I go there, it'd 
be $1000*x for travel and $600 for participation, so we are better off 
with staying here and paying a remote fee of $1000. But in general, how 
it'll work out is if you stay at your home location, you'll work much 
more for your day job, you have difficulties to pretend that you are not 
around, you won't meet new people interested in similar subjects, you 
won't get new ideas simply from being in a different location, and so 
on. I guess most if not all managers will understand that and will 
easily say: Why would we have to pay more for remote, that should be 
less, shouldn't it!

Regards,   Martin.