Subject: [Mtgvenue] New Version Notification for draft-baker-mtgvenue-iaoc-venue-selection-process-01.txt

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 17 Mar 2016 19:39:24 +0000

A new version of I-D, draft-baker-mtgvenue-iaoc-venue-selection-process-01.txt
has been successfully submitted by Fred Baker and posted to the
IETF repository.

A review of the diff, hopefully, shows that I picked up the comments from our discussion last week. If folks think I have missed the mark on those, please say so on-list.

There are two comments, both from Olaf Kolkman, that I didn't pick up as I wasn't quite sure what to do with them...

On Mar 10, 2016, at 8:06 AM, Olaf Kolkman <[email-masked]> wrote:
> Also 3.1, the Internet Access part: Meeting attendees need unfiltered access. This comes back as a Mandatory meeting requirement.
> 
> Sensitive issue.
> 
> I've been to places where there were filters for content that I did not need to do my job e.g. filters for adult content. I highly prefer unfiltered access. I realize that if we move away from the unfiltered requirement clearly formulating what is and what is not accessible is going to be problematic. But I think you may be excluding reasonable places that might be acceptable even though some filtering is taking place.
> 
> Perhaps this is not a Mandatory or Desired property. But one of the type where if the requirement cannot be met some other highly desired properties must be in place to compensate.

> On 3.3.1 The Travel Barriers to entry_ and Economic, safety, and health risk seem requirements for a process, not a requirement on the outcome. A requirement would provide a metric by which you can require when you will walk away? The other requirements are also somewhat fuzzy.
> 
> I have no issue with any of that but it seems that it is probably better to not phrase these as criteria but as considerations of certain level of importance. Travel barriers would be a high level of importance in making the decision, while multi-event would be a mid-level of importance.
> 
> Most of the criteria in 3.3.2, 3.3.3, 3.3.3.4 are much more focused on defining a measurable outcome.

The draft version:

Name:		draft-baker-mtgvenue-iaoc-venue-selection-process
Revision:	01
Title:		IAOC Plenary Meeting Venue Selection Process
Document date:	2016-03-17
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/internet-drafts/draft-baker-mtgvenue-iaoc-venue-selection-process-01.txt
Status:         https://datatracker.ietf.org/doc/draft-baker-mtgvenue-iaoc-venue-selection-process/
Htmlized:       https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-baker-mtgvenue-iaoc-venue-selection-process-01

Abstract:
  This documents the IAOC's IETF Meeting Venue Selection Process.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 18 Mar 2016 10:56:04 +0100

> There are two comments, both from Olaf Kolkman, that I didn't pick up as I wasn't quite sure what to do with them...

Let me try to condense those two comments into one issue: Turn criteria into considerations.

Trying to rephrase what I said before to support that suggestion, this is both a style and a substance issue.

The Mandatory requirement says "Walk Away" and establishes strong guidance on what to do if a criterium is not met. Stylistically, that means you have to provide measurable thresholds in order to understand what to do. There are criteria where that is done well:

	The meeting venue must permit and facilitate the delivery of a
    high performance, robust, unfiltered and unmodified IETF Network.

As a criterium this is clear: if the network is in any way filtered or modified, we walk. In my previous note I argued that I find this criterium to black and white (that is substance, will not repeat it here).

In other places in the document the criteria are more vague

	Travel to the venue is reasonably acceptable based on cost, time,
	and burden for participants traveling from multiple regions.  It
	is anticipated that the burden borne will be generally shared over
	the course of the year. [Mandatory]

This doesn't give any guidance on when to walk. In contrast to the network criterium above this seems to be phrased as a consideration.

Another example (also a style issue):

	Travel barriers to entry, e.g., visa requirements that can limit
    participation, are researched, noted, and carefully considered. [MANDATORY]

This is a criteria to follow a process, it doesn't say when we walk.

I think that we may solve this if approach these criteria as considerations of various importance. The outcome of a consideration (such as Travel Barriers to Entrance) is then given a certain weight in the decision. We document which considerations are more important to others. In fact I think that is the tone and the way that most of the document is written anyway.

It would solve my substantive issue too. It would make the network requirement slightly less black and white, I am fully on board making that one of the most important considerations.

Hope this clarifies….

—Olaf

- - -
Olaf Kolkman                                                         [email-masked]
Chief Internet Technology Officer
Internet Society                                                     www.internetsociety.org
                                                                     LinkedIn: OlafKolkman
                                                                     Twitter: @Kolkman
- - -

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Mar 2016 07:55:19 -0700

> Let me try to condense those two comments into one issue: Turn criteria

Olaf,

There is a tendency in doing IETF process-related documentation to 
ignore what we know about protocol specification.  Interoperability 
requires a clear, core set of mandatory behaviors.  But for IETF process 
work, we like to leave things subjective and tentative, as if that will 
reliably produce acceptable results, when we have almost 30 years of 
experience showing that it reliably produces problematic results.

You correctly note some basic differences in the style of the criteria. 
  That is because some are about the selection process itself, while 
others are about the resources being selected.  Think of it as protocol 
(process) vs. payload (venue resources)...

In terms of mandatory process items, the issue is not that there might 
be a 'walk away' condition, but that we need to make sure anyone 
involved in the process knows of the explicit requirement an satisfies 
it.  This also means documenting it for possible later review.

For a mandatory criterion on the venue itself (the payload), the basis 
for deciding that it must be mandatory was an assessment that failure to 
satisfy it inherently puts the meeting at risk.

Note that there is provision for exceptions; if the Meetings Committee 
and/or IAOC feel that it is reasonable for a criterion not to be met, it 
must pursue this explicitly, seeking IETF-wide approval.  So the 
flexibility you seek is already provided for.  The difference is that it 
is made an explicit exceptions process, rather than the 
frequently-problematic approach of undocumented and often unrecognized 
subjectivity within the process that has been in place.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 18 Mar 2016 16:35:43 +0100

On 18 Mar 2016, at 15:55, Dave Crocker wrote:

> There is a tendency in doing IETF process-related documentation to ignore what we know about protocol specification.

You say as if that is a bad thing. ;-)

We are not programming computers. I think we should write these documents to allow for judgement. Perhaps that is where we differ in opinion.

I have a preference for turning all requirements into process requirements.  That includes a requirement that  for those cases where failing a requirement puts the meeting at risk that risk assessment is explicitly made an documented. For that specific point I've been using as an example that may result in documentation like this:

"In venue X we found access to adult content blocked, this doesn't pose a risk for participants not to show up or to don't allow them to do their work."

"In venue Y we found access to social networks blocked, this poses a risk to the meeting since a large number of key contributors will not show up as it is considered unreasonable censorship."

Yes, that would involve making a politically colored decision. As it stands now you are making that  political risk assessment at requirements time.

Regardless, I think that the 'Requirement Language' doesn't work for what you identified as process requirements.

—Olaf

- - -

---

From: Dave Crocker <[email-masked]>
Date: Sat, 19 Mar 2016 12:20:32 -0700

Olaf,

On 3/18/2016 8:35 AM, Olaf Kolkman wrote:
> We are not programming computers. I think we should write these
> documents to allow for judgement. Perhaps that is where we differ in
> opinion.

Perhaps you have forgotten that use the word 'protocol' was for human 
conduct, long before being applied to computer networking.  The need for 
basic and precise about conventions on behavior and choice, which are 
known and used by all participants, is in the nature of systems 
interactions, and does not depend on who (or what) the actors are.

In the IETF, there is a compulsive invocation of the need for 
'judgement' in management decisions, as if there is no history of 
problems with that fallback and as if the handling of problems with that 
approach have been adequate.

The effort for this document came out of concern for a continuing 
pattern of complaints -- where the common and condescendingly disdainful 
dismissal of the complaints as merely whining no longer suffices.

Basically, excessive reliance on 'judgement' for an activity like this 
means that those making the decisions constantly need to guess what will 
satisfy the community and the community can then formulate whatever new 
and undocumented criteria it wishes.

Essentially, there is no shared learning curve, since for every next 
time, there will be different people making the choices.  Even if the 
same people were doing the decision-making, the lack of precise criteria 
means that no one can be held accountable, since they can always simply 
claim that they made a judgement.

I've been close to the venue selection efforts for a number of years 
recently, as well as periodically over the entire life of the modern 
IETF.  Everyone I've seen who works on this topic means well.  In spite 
of that, the actual process of venue selection tends to be remarkably ad 
hoc, at a number of points along the process, with decisions often 
merely representing a few folks' individual preferences of the moment. I 
see this as largely due to the operational model being one of having 
everyone apply their personal sense of judgement, rather than having a 
sufficiently clear and robust set of specific requirements.  If the 
results of those moments of personal preference were always comfortable 
for the community, we would not be having this discussion.

In recent years, there's been a set of de facto rules that are used and 
indeed, I believe the track record for community reactions to venues has 
gotten markedly better. However the continuing, periodic community 
DISsatisfaction makes clear that it hasn't gotten better enough.

There needs to be a stable and precise set of criteria so that we can 
get more reliable results in venue selection.  This includes being able 
to respond to new criteria from the community by having an explicit 
exchange /noting/ that the criteria are new and then considering whether 
the criteria need to be applied going forward.

> I have a preference for turning all requirements into process
> requirements.

Imagine a protocol with no payload.  That's what you are seeking.

Well, ok.  Actually you are calling for a protocol that has 
self-defining payload.  And indeed some protocols have done that.  And 
it works well, for extensible (transparent) carriage, but not for 
interoperable semantics between the actors.  The latter is the issue here.

> That includes a requirement that for those cases where
> failing a requirement puts the meeting at risk that risk assessment is
> explicitly made an documented.

No, actually, it doesn't.  Because there won't be any stable and precise 
and shared criteria.  There will only be community outcry, post hoc.

So while those making the decisions might make some good guesses about 
what issues to document, they won't guess correctly all the time.

Worse, it's not fair to the folk making the decision to require such 
guessing, since it's a bit like being at a restaurant and demanding that 
the waitperson do the ordering for you. And then criticizing them for 
getting the order wrong.

> Regardless, I think that the 'Requirement Language' doesn't work for
> what you identified as process requirements.

The group put quite a bit of effort into trying to make the text clear, 
substantive, relevant and minimal.  If it isn't working for you, please 
provide details.

d/

-- 

   Dave Crocker