Re: [Mtgvenue] comments on draft-ietf-mtgvenue-iaoc-venue-selection-process-04

[Eliot Lear <[e-mail]>]

Hi Stephen,


On 1/30/17 5:10 AM, Stephen Farrell wrote:
> Thanks for developing this document, I'm sure it'll help us
> avoid some repeated discussions when done.
>
> My apologies for not having participated until now but please
> find a bunch of comments below.
>
> Please feel free to ignore any that have already been
> discussed - I only had time for a quick peek at the archive.
>
> Cheers,
> S.
>
> - general: I think there's a statement missing, viz: "The
> IETF's meeting venue selection process, as with all IETF
> processes, should be as open as possible." Could we add
> that or similar to the intro?

What do you practically have in mind?  One could go too far with regard
to certain aspects of contract negotiations.  What's possible and what's
advisable?

>
> - 1.2, mandatory: Do we somewhere address the temporal
> aspect of this where a venue used to be (un)acceptable but
> that changes? I'm not clear how such changes on the ground
> impact on the process described in section 5. (Nor do I
> have a good suggestion to offer sorry;-)
>
> - 1.2, important: While I get the good intention here, I
> don't know how I would evaluate this, were I ever on the
> IAOC. Is that just me? Despite it being hard to do, I
> suspect 2119 terms might work better here, with the
> definition of SHOULD (as always) being "MUST except when
> <X>" for some X that ought be documenntable at the time of
> a meeting venue decision. The meat of that change would I
> think be that, "Important"/SHOULD requirements would be
> treated as Mandatory/MUST requirements in all cases except
> when there is a specific stated (or can-be-stated) reason.

We need to disentangle the two issues you are raising here.  One is how
to evaluate tradeoffs and the other is the "normative" language.  Let's
start with the 2nd first, because I think it's easier to address.  The
good about 2119 language is that we all know what it means.  The bad is
that in this case, it doesn't really apply.  In particular, MUST's use
is constrained in an inapplicable way in Section 6 of RFC 2119.  In
addition,  the authors have made clear "important" may involve a
tradeoff.  From a transparency perspective, that should be made clear.

As to how you evaluate what to trade off, this is where your judgment
comes in.  Which of these "important" things is more important at a
given moment?  That's why you'd get the big bucks ;-)

>
> - 1.2, inclusiveness, bullet 1: as has become apparent this
> week, "entry" is not the only barrier to consider.  We need
> somehow to consider "going home" as well and maybe even
> (though with lower probability) issues that might arise
> in-transit, if route selections are v. limited. That might
> be better done in it's own sub-section, not sure.

I think in the instant circumstances, what you're suggesting would be
unworkable for three  reasons.  First, we can only control where the
conference is, and not where people come from (and therefore would be
returning to).  Second, probably we don't want to meet in countries that
are causing such strife, but, third, if we attempted to hold all
conferences in venues where exiting were not a problem, probably
entering would be.

>
> - 1.2, "unfiltered" - do we need to define that a little
> better? I'd suggest we define it as whatever at the time
> constitutes IETF consensus on the level of access that is
> considered acceptable for typical home/office use for any
> non-negligibly-sized subset of IETF participants. It may be
> worth noting that a BCP could be a good way to document
> that consensus, but is not needed for this document. Such a
> BCP would be a moving target, but it's correct that it
> ought be.  (Same term occurs in 3.3 btw)
Got text?
>
> - 2.2, politics: I'd argue that we ought add to the end of
> this "... except where such issues significantly impinge on
> the ability of IETF participants to work effectively."

I thought that was implicit, but I'm personally okay with this addition.
>
> - section 3, 2nd para: ought we require the IAOC to be able
> to publicly justify its reasoning after it has made a venue
> selection decision? I'd like that that be possible and that
> IAOC members work on that basis, but there's a risk that
> some of us might abuse such a requirement. So I'm not sure
> what's right here.

Did that not happen in BA and thereafter?

>
> - really a nit, but best stated here: it'd be better if
> the rows in the tables had a unique number, to make it
> easier to discuss 'em now and later (when folks talk about
> why criterion-foo is/isn't met).

My nit is slightly different.  I'd suggest the list be ordered from
mandatory downward.
>
> - 3.1, consultation: There's a missing temporal aspect here
> and elsewhere. I think in this case what's meant to be
> mandatory is that the community has been consulted
> sufficiently far ahead that changes are still possible.
> But we also need to recognise that situations may change,
> and even close to a meeting so that there's no real
> alternative but to stick with the now-bad plan. (Or to not
> meet at all.)

We have to be rather careful about this, lest the organization take big
financial hit.  What do you have in mind?

>
> - 3.1, host/sponsors: I don't think this ought be mandatory
> as we may move from a sposor-related-to-venue model to some
> other ways in which sponsors help out.  It might be better
> to cast this as a negative, i.e. to say that it is
> mandatory to ensure that a venue is not sponsor-unfriendly
> to a significant degree and I'd also s/mandatory/important/
>
> - 3.2, "within the norms of business travel": I don't like
> that characterisation - IETF participation might in future
> not live up to that budget. Ought we say "acceptable to IETF
> participants in general" maybe.

Didn't we just get away from having to evaluate what that means?

>
> - 3.2, "net cash positive": a question wrt "allow the
> meeting to be" - does that mean "has to be" or "could be"?
>
> - 3.2: I don't get the distinction with "wheelchair" being
> mandatory and "accessible to people with disabilities"
> being only important. That seems like a contradiction to
> me. (Same in 3.4) Can you explain?

Funnily enough I wondered about the distinction as well, even what it
meant.  And so I went and asked a well known accessibility expert
(Andrea Saks) about this.  She pointed out that this would have to do
with whether elevators have braille, whether there are bedrooms are set
up for deaf people (doorbell lights, and such).  I'm going to hazard a
guess that many venues outside the US are in some way partial compliance
with what we Americans would call the ADA.  I'm guessing that's what
this is about.  A good # of UN buildings (including the ITU) have some
limitations along these lines, for instance.

>
> - 3.5, "health/religion related diets": I think this ought
> only be important and not mandatory. I fully understand why
> those affected would disagree but IMO promoting this to
> mandatory would be paying too much attention to reasonable
> people who are noisier than other reasonable people.

Keep in mind the text of the full requirement (which I'll note with
tables in text is hard to cut and paste):

   A range of attendee's health-related and religion- 
   related dietary requirements can be satisfied with
   robust and flexible onsite service or through access
   to an adequate grocery.


And so the text doesn't REQUIRE on prem accommodation, but something
nearby.  Also note that it specifies "a range".  That is subject to
judgment.

>
> - section 4: I think this ought be deleted. There is no need
> for tutorial material and what's here could be invalidated
> by a re-org of IASA, which has been mooted for this year.
> Sections 4.6 and 4.7 are the worst in that respect, in that
> they could be a barrier to some changes in IASA that the
> IETF may or may not wish to explore.

I think I agree.  If this updates or clarifies those roles, we should be
clear on how it does so, and we should note that with "Updates:".
>
> - section 5: this overall seems too prescriptive to me.  Do
> we really think we'll need to follow this process *exactly*
> in say 2027? I'd say making this all less prescriptive
> would be better.

Yes, I like the idea of it being DEscriptive.

> - 5.3 & 5.5: the links aren't a good idea (and are access
> controlled which is unacceptable if not fixed).
>
> nits
>
> - abstract: to me, "IETF plenary" means Wednesday night fun
> (currently:-) and not the full week. Suggest rewording
> that.
>
> - section 1: does this really describe thought processes?
> I doubt it. Perhaps you mean reasoning?
>
> - 1.2, desired: I'm not clear that this definition does not
> overlap with "Important"
>
> - 1.2, why do we meet: I think it'd be worth stating that
> we also meet so that in-person interaction smoothes later
> virtual interactions. There is agenda-independent (and
> dinner-independent:-) value in meeting f2f at least
> sometimes, if not regularly. That point could be noted
> below under "Focus" but would be better in the "Why do we
> meet" headline bit I think.
>
> - 1.2: " Within reason, budget should not be a barrier to
> accommodation." Huh? I don't get what's meant there, and it
> could be ambiguous.  Maybe better deleted as the para as a
> whole seems to state the concept well enough?
>
> - 2.2, tourism: I think we ought recognise that people do
> work better and do better work when happy. And people are
> happier in some venues than others, often for the same
> reasons that cause tourists to like a particular venue.
> I'd still leave tourism in this section but I'd argue to
> qualify it along the above lines - while we don't want to
> travel for tourist reasons, we equally do not need to avoid
> nice locations and seek out the horrendous:-)

require_once "MinneapolisDiscussion.php";


>
> - section 3: I'm not sure that "IETF hotel" and SSIDs are
> that closely related.
>
> - 3.2: I'm not sure the IETF is an "internaltion
> organisation" and I'd prefer we not call ourselves that.

There are words we can probably pull from our IANA response or from the
Tao as to how we describe ourselves.  I agree that we have to be careful
about how we characterize ourselves here, and it's perhaps a little more
than a nit.
>
> - 5.1: I don't get why we need to be as prescriptive as
> "four years out.."
>
>

Regards,

Eliot