Subject: [Mtgvenue] can we make an RFC for the venue selection process?

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 02 May 2017 19:33:43 +0200

Hi all,

During all last week, I’ve participated in a very interesting experience that I believe is important to share with this WG.

I was assisting the AMS/NOC team in the survey of 8 different venues (plus a few overflow hotels) in a couple of cities.

Before that, I’d already a lot of ideas of what are our needs, and in fact, I worked in draft-palet-ietf-meeting-venue-selection-criteria-04, and of course, I’m following this list and the meetings.

However, actually participating in the process I feel that we are getting wrong draft-ietf-mtgvenue-iaoc-venue-selection-process-06.

I wish that all the contributors in this effort actually have the opportunity to participate in this activity (on-site venue survey) before actually contributing to the document in a way that it works. Believe me, it will be useless if we approve a document that is not based in REAL EXPERIENCE. Moreover, I did the exercise of trying to “pass” venues where we had successful meetings, and only a couple of them, in the last years, actually worked.

Again, I’m not talking about “theoretical”, but what I’ve seen in the IETF meeting, as I started participating in London 2001 and since then I’ve been in all them, not missing any, so I’ve been able to see in my own skin what it worked and what not …

We are a technical standards organization, and RFCs are very good for defining protocols, algorithms and so, that can be turned in to actual code. However, it is very clear now for me that we can’t use an RFC to enforce a venue coalification. This will bring us to the situation that only 4-5, maybe 6 venues in the world, work for us.

Is that what we are looking for?

We may need a “special” document, not what we understand as an RFC, and different requirements language to make it work.

In a generic way, the term Mandatory, as described in 1.2 of the actual document, is useless, and will only mean that we need to consult the community 95% of the venues that already worked before for successful meetings.

I think we need a document that can be used by the “on-site venue survey team” as a guidance, not as a document to “match” the venues with. Believe me this will not work and will be a tool for endless debates.

Maybe, if we just relax what Mandatory means, then it may work, but only maybe. For example:

Actual:
Mandatory:
      If this requirement cannot be met, a particular location is
      unacceptable for selection, and no contract is to be entered into.
      Should the IAOC learn that a location no longer can meet a
      mandatory requirement after having entered into a contract, it
      will inform the community and address the matter on a case by case
      basis.

New:
Mandatory:
      If this requirement cannot be met, a particular location will need
      further examination and a balance among “mandatory” and
      “important” and “desired” will be required towards a final decision.
      by the IAOC. In extreme situations, the IAOC will consult with the 
      community.

Alternatively, instead of an RFC, we may think that this must be a web page with all the information as “recommendations” or “guidelines” for venue requirements.

As I’ve re-read several times the actual document during last week, I also have some other inputs (many of those related to the past week experience), which I’m addressing one by one:

1) Section 2.1 point 2, should include “freedom of expression for the participants”.
2) I think we must not hold meetings in venues that allow people to carry firearms. I know this may be a conflict for many people that believe that self-defense is a right, but I agree that is true in the street, but inside a venue? If a venue is not considered safe so it “encourages people to carry a gun”, then there is no discussion on that, we should not meet in that venue.
3) At 3.2 the reference “There are sufficient places (e.g., a mix of hallways, bars, meeting rooms, and restaurants) …” is for the facility or the venue/city? Actually, I think is not the same and we may need to split that in 3 equivalent requirements, one for the facility, one for the hotel, one for the facility neighborhood. For instance, we may find a conference center with is plenty of much more space that what we need, but the hotel may have no space, or on the other way around. Or the hotel maybe has no restaurants but across the street (2’ walk) you have a shopping center with offers 20 options.
4) “The Facility permits easy wheelchair access”. While I agree this is a kind of “MUST” in our usual terminology, what it means “easy”? Regulations in different countries may provide a different meaning for “easy”, so I think we should delete “easy”, because it turns into something very subjective.
5) In the past, we were talking about 350 guest rooms at a minimum in the “headquarter hotel”. Now we have “The guest rooms at the IETF Hotel(s) are sufficient in number to house 1/3 or more of projected meeting”. I recall we had this discussion because the Intercontinental at Yokohama. I think we need to have a clear vision that if we have 3 or 4 hotels instead of just 1-2 that fulfill let’s say, the coverage needed for 75% of the participants, that should be enough if they are in very close proximity. For example, one hotel next to the other in the same street, or across the street, and walking 5 minutes or so bring you to the meeting facility.
6) Same consideration as in 4 above to remove “easy” at “The IETF Hotel(s) permit easy wheelchair access”.
7) “The IETF Headquarters Hotel has a space for use as a lounge …” This text need to be rewritten, as it is assuming that there is only one “headquarter” hotel. What if we have 4 as main hotels, because among them fulfill our needs?
8) “The Venue environs, which includes both onsite, as well as areas within a reasonable walking distance or conveniently accessible by a short taxi, bus, or subway ride, have convenient and inexpensive choices for meals that can accommodate a wide range of dietary requirements.“. Replace “short taxi, bus, or subway ride” with “short taxi ride, or any other public transport service”, this way opens other choices with are not bus or subway, which are available now in cities or may be available in the future …
9) This may be an English issue “grocery shopping” includes small markets, supermarkets, hypermarkets, local shops, etc., just to be on the safe side.
10) I think it will be VERY important to have a local, which is also involved in the IETF, and knows the venue and the neighborhood of the facilities being evaluated, to help the on-site survey team. This could be added to 5.3 Qualification.
11) Appendix A should not be a MUST, is an overall reference. There are many parameters there that may change depending on the set of: facility + hotels + neighborhood.

Regards,
Jordi

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 May 2017 13:46:17 -0400

Dear colleagues,

> In a generic way, the term Mandatory, as described in 1.2 of the actual document, is useless, and will only mean that we need to consult the community 95% of the venues that already worked before f…

I don't see why.

>       will inform the community and address the matter on a case by case

The point is that, if something is Mandatory, then it really is a hard
requirement.  For instance, having enough rooms to put us in is
_Mandatory_ in the sense above.

I agree with you, however, that many of the versions of the document
had lots of stuff that was Mandatory but didn't meet that threshold.
I think that we have to force ourselves to lower our expectations in
such a case, not redefine Mandatory to mean somehow "really super
important though, we mean it" or "we had better think about it" or
whatever.

In 2119 language, it's a MUST: without this, you do not conform,
period.  We should have the minimum we need, and no more, to make the
thing work.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 02 May 2017 19:58:56 +0200

And precisely because that is broken. RFC is for something “strict” it must have MUST, because we need protocols to interoperate.

Selecting a venue is not the same thing.

Let me ask this: Have you participated in an actual on-site survey? Other participants have done it?

I will have answered the same as you did regarding MUST, before having participated, but as said, now I’ve a different and realistic view.

I think is very difficult to explain, but in summary, I think all our MUST can have a balance among all our needs and having that kind of working will means very very very few venues will work if the IAOC applies it as a MUST, so we are forcing to inform the community in almost every possible venue.

May be the point is remove mandatory and set it as “very important”, but definitively not needing a community check for every possible venue ?

Regards,
Jordi

-----Mensaje original-----
De: Mtgvenue <[email-masked]> en nombre de Andrew Sullivan <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 2 de mayo de 2017, 19:46
Para: <[email-masked]>
Asunto: Re: [Mtgvenue] can we make an RFC for the venue selection process?

    Dear colleagues,

    I don't see why.

    

    Best regards,
    
    A
    
    -- 
    Andrew Sullivan
    [email-masked]
    
    _______________________________________________
    Mtgvenue mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/mtgvenue

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 May 2017 14:17:11 -0400

> Let me ask this: Have you participated in an actual on-site survey? Other participants have done it?

I was on the IAOC that selected the site of IETF 100, and I believe
that some Mandatory things really are mandatory, and the others are
not.  I think one can know that _a priori_, without doing any site
visits or anything of the sort.

I agree very strongly with you that many, many of the things we really
want are still matters of trade-off.  I don't believe "enough rooms
actually to hold the meeting in" is one of those: if the Facility
doesn't have enough rooms of the right size and close enough to one
another that we can get around to them, then it's not a facility for
us _no matter what else_ you trade off.  We can't go there because we
can't actually have our meeting.  Note that this doesn't mean
"comfortably spacious" (Prague is a little tight) or "easy to find"
(the London Metropole misses here), but the basic requirement is
mandatory, not tradeable.  We can't hold the IETF meeting in a
boutique hotel with a function room that holds 10, and nothing we
trade off is going to change that.

> May be the point is remove mandatory and set it as “very important”, but definitively not needing a community check for every possible venue ?

The lastest draft has downgraded an awful lot of formerly Mandatory
requirements.  Are you sure you've read the latest?

A

-- 
Andrew Sullivan
[email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 02 May 2017 20:25:34 +0200

[Jordi] I meant actually surveying venues.

[Jordi] Fully agree here, VERY FEW are a real MUST.

    
 
I’m reading https://tools.ietf.org/html/draft-ietf-mtgvenue-iaoc-venue-selection-process-06.

    A
    
    -- 
    Andrew Sullivan
    [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 02 May 2017 20:37:03 +0200

Let me to add some clarification here.

When you see a facility floor plants, when you read info about it, even when you read reports from people who surveyed it, you may get an impression that is big enough or is too small, and this impression may be wrong. If you try to match that with a requirements document, you will have it wrong.

Last week I saw facilities that on the paper look small, but actually when you visit them, they have sufficient meeting rooms for us. I saw also the contrary situation, so they look insufficient for us, but then on-site, they are big enough.

Also saw perfect venues that lack of sufficient break-space, or what it was looking a bad venue as nearby facilities that are much better than some of our “usual” venues (as Prague) just crossing the street (actually taking even less time that moving inside a BIG venue).

I think making MUST, even for a few things, we may be missing opportunities of venues that will work in a different way that we are used to, or forcing the IAOC to “go beyond” our own “RFC” rules, or asking the community for commenting about choices that if the survey team that actually visited the venue said “it is perfect for us”, we should not be wondering and wasting time from the community (or even the IAOC, which seems overloaded and not being able to catch up with emails since August 2015) even if those venues don’t match some MUST, but will work for us.

Regards,
Jordi

-----Mensaje original-----
De: Mtgvenue <[email-masked]> en nombre de JORDI PALET MARTINEZ <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 2 de mayo de 2017, 20:25
Para: <[email-masked]>
Asunto: Re: [Mtgvenue] can we make an RFC for the venue selection process?

    

    

     
    
        A
        
        -- 
        Andrew Sullivan
        [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 May 2017 14:47:44 -0400

> When you see a facility floor plants, when you read info about it, even when you read reports from people who surveyed it, you may get an impression that is big enough or is too small, and this imp…

I don't think anyone was suggesting that the requirements have to be
met only by looking at paper.  For instance, if someone offered you a
floor plan for one of the many hotels that have been torn down in Las
Vegas, it would have enough rooms and they would be big enough and so
on.  But the hotel would still not meet the requirement, since it
doesn't exist any more.  The requirement is just this:

   +-----------------------------------------------------+-------------+
   | The Facility is assessed to be able to provide      | "Mandatory" |
   | sufficient space in an appropriate layout to        |             |
   | accommodate the expected number of people to attend |             |
   | that meeting.                                       |             |
   +-----------------------------------------------------+-------------+

I should think that "is assessed" could include site visits or
whatever.  It's still a Mandatory requirement.

If the above requirement does not meet the threshold for Mandatory,
then I agree with you that there isn't anything that could qualify.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 2 May 2017 15:12:57 -0400

Andrew,

"easy to find"
> (the London Metropole misses here)
>

I’m not sure where that comes from. It’s a short walk from three
underground stations, and you can’t miss it if you’re walking anywhere in
the area. If you’re driving, it’s just a straight shot up Edgware Road from
Hyde Park and Marble Arch.

Cheers,
Andy

---

From: Ole Jacobsen <[email-masked]>
Date: Tue, 02 May 2017 12:18:46 -0700 (PDT)

Jordi,

I am glad that you were able to participate in a site selection visit
and assist the rest of the team with your local knowledge.

Keep in mind that several of the authors listed for the Meeting Venue
Draft are long time IETF attendees (I have attended 91 meetings) and
some are even part of the site visit team (Jim, Laura).

There is no disagreement about the need for an actual on-site visit
nor the need for a SECOND visit closer to the actual meeting. Folks
will be going to Prague soon for this very reason. 

The Meetings Committee relies heavily on the site visit reports and
of course those reports are part of the deliberations that lead up
to the committee's recommendation to the whole IAOC.

The need for community input was clearly illustrated by the IETF-100
announcement in which it was felt that the IAOC had ignored or missed
a major condition. We can argue about how that condition would/will
affect our ability to have a successful meeting, but at least now we
do have a procedure for asking "have we missed something?"

Ole (speaking for myself only)

Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office:  +1 415-550-9433
Cell:    +1 415-370-4628
Docomo:  090 3337-9311
Web: protocoljournal.org
E-mail: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 May 2017 15:31:08 -0400

On Tue, May 02, 2017 at 03:12:57PM -0400, Andrew G. Malis wrote:
> underground stations

No, no, sorry, I meant the room layout inside.  Last time, we had
rooms all over the place, and AMS made the directionally-challenged a
video of how to get around :)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 May 2017 15:40:25 -0400

> video of how to get around :)

That was kind of awesome.   The elevator to the rooms in the weird little downstairs annex was a bit slow, though.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 03 May 2017 10:41:31 +0200

Hi Ole,

Of course, I was not referring to Laura, Marcia, Jim or Ray, which have done lots of on-site-surveys, but the rest of the participants in the WG.

I’ve participated in 51 meetings, all in a raw, and despite that, I’ve never realized many “behind the scenes” details that now I’m aware of. In addition to that, I’ve organized myself several “big” events, ranging from 450 people to 3.500, and despite that experience, I still learned a lot of new things last week.

I’m not trying to be impolite, maybe I didn’t used the correct wording. I’m trying to say, that I’m not sure an RFC is a valid format unless we relax it.

I also know about the follow up visits when a venue is selected, etc., and in fact I already knew most of the venues (I should say facilities according to the document wording) that we were visiting, I’ve done my own events on those, even installed in one of the them the first optical fiber they had many years ago, and I “surveyed” the venues myself last year, before this “official” survey was done last week. Again, despite that, I learned a lot of new things, because our requirements are somehow “different” or “special” vs other events. And again, regular participants don’t appreciate those differences, because somebody worked them out for us. So, trying to write a document not having been behind the scenes and not having done this job before, is not that good as we may believe.

It is like asking somebody that has actually not deployed IPv6 to contribute to an operational document.

Do we want to make a too strict document that means more difficulties and much more complex and slow work for the meeting committee and the IAOC, or we want something realistic? As much as I think on this, much convinced I’m that we want a “very/highly important, may imply community consensus/consultancy” but not a “mandatory”.

Regards,
Jordi

-----Mensaje original-----
De: Mtgvenue <[email-masked]> en nombre de Ole Jacobsen <[email-masked]>
Responder a: Ole Jacobsen <[email-masked]>
Fecha: martes, 2 de mayo de 2017, 21:18
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [Mtgvenue] can we make an RFC for the venue selection process?

    Jordi,

    

    

    Ole J. Jacobsen
    Editor and Publisher

---

From: Eliot Lear <[email-masked]>
Date: Wed, 3 May 2017 13:57:20 +0200

Hi Jordi,

I just want to capture some issues in this post so that we don't lose
track of stuff we haven't already covered:

> 1) Section 2.1 point 2, should include “freedom of expression for the participants”.

https://github.com/elear/mtgvenue/issues/22

> 2) I think we must not hold meetings in venues that allow people to carry firearms. I know this may be a conflict for many people that believe that self-defense is a right, but I agree that is true…
https://github.com/elear/mtgvenue/issues/23
> 3) At 3.2 the reference “There are sufficient places (e.g., a mix of hallways, bars, meeting rooms, and restaurants) …” is for the facility or the venue/city? Actually, I think is not the same and…

I'm having difficulty understanding your intent.  I think the point was
to look at the Venue as a whole precisely to address the issue you are
raising.
> 4) “The Facility permits easy wheelchair access”. While I agree this is a kind of “MUST” in our usual terminology, what it means “easy”? Regulations in different countries may provide a different m…

Right.  This is an open issue (#14).
https://github.com/elear/mtgvenue/issues/14.  I think Alissa has a
pointer to an ICANN person who might have some language we can borrow.

> 5) In the past, we were talking about 350 guest rooms at a minimum in the “headquarter hotel”. Now we have “The guest rooms at the IETF Hotel(s) are sufficient in number to house 1/3 or more of pro…

I think this is intended to be covered by the definition of IETF hotel
(there can be more than 1).

> 6) Same consideration as in 4 above to remove “easy” at “The IETF Hotel(s) permit easy wheelchair access”.
Right.

> 7) “The IETF Headquarters Hotel has a space for use as a lounge …” This text need to be rewritten, as it is assuming that there is only one “headquarter” hotel. What if we have 4 as main hotels, be…
https://github.com/elear/mtgvenue/issues/24.

> 8) “The Venue environs, which includes both onsite, as well as areas within a reasonable walking distance or conveniently accessible by a short taxi, bus, or subway ride, have convenient and inexpe…

Ok.  Handled editorially.

> 9) This may be an English issue “grocery shopping” includes small markets, supermarkets, hypermarkets, local shops, etc., just to be on the safe side.

Webster's definition covers this sufficient, IMHO.

> 10) I think it will be VERY important to have a local, which is also involved in the IETF, and knows the venue and the neighborhood of the facilities being evaluated, to help the on-site survey team. This could be added to 5.3 Qualification

https://github.com/elear/mtgvenue/issues/25
> 11) Appendix A should not be a MUST, is an overall reference. There are many parameters there that may change depending on the set of: facility + hotels + neighborhood.
Where does it say that Appendix A is a MUST?

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 May 2017 09:12:51 -0400

> I was assisting the AMS/NOC team in the survey of 8 different venues
    > (plus a few overflow hotels) in a couple of cities.

...

    > I wish that all the contributors in this effort actually have the
    > opportunity to participate in this activity (on-site venue survey)
    > before actually contributing to the document in a way that it
    > works. Believe me, it will be useless if we approve a document that is
    > not based in REAL EXPERIENCE. Moreover, I did the exercise of trying to
    > “pass” venues where we had successful meetings, and only a couple of
    > them, in the last years, actually worked.

Could we get more feedback from other people involved in the site visits?
Jim Martin goes... I'm not sure who else.

    > We may need a “special” document, not what we understand as an RFC, and
    > different requirements language to make it work.

I understand.
I think that what the community really needs is to have the IAOC narative
about the tradeoffs they made become public.   We may not need to see the
words of the contract, but we might need to see the table of contents
and see a summary.

    > 5) In the past, we were talking about 350 guest rooms at a minimum in
    > the “headquarter hotel”. Now we have “The guest rooms at the IETF
    > Hotel(s) are sufficient in number to house 1/3 or more of projected
    > meeting”. I recall we had this discussion because the Intercontinental
    > at Yokohama. I think we need to have a clear vision that if we have 3
    > or 4 hotels instead of just 1-2 that fulfill let’s say, the coverage
    > needed for 75% of the participants, that should be enough if they are
    > in very close proximity. For example, one hotel next to the other in
    > the same street, or across the street, and walking 5 minutes or so
    > bring you to the meeting facility.

Just permit "headquarter hotel" to be be "headquarter hotel(s)", and explain
what it means to have a headquarter. Probably something involving networks,
walking and "easy" wheelchair access (without coats)... maybe other details.

Yokohama didn't have a canonical bar which was a problem; the lounge did make
up for it.   I claim canonical bar should be among the top-5 considerations.

Chicago *did* have a canonical bar. The lounge was hard to find the first
time, but was well used.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 May 2017 09:16:59 -0400

> Jim Martin goes... I'm not sure who else.

Of course, he's one of the authors. Duh on me. I just hadn't seen any posts
From him :-)

---

From: Yoav Nir <[email-masked]>
Date: Thu, 4 May 2017 21:20:45 +0300

> On 3 May 2017, at 14:57, Eliot Lear <[email-masked]> wrote:
> 
> Hi Jordi,
> 
> https://github.com/elear/mtgvenue/issues/22 <https://github.com/elear/mtgvenue/issues/22>

OK. Why? I don’t think anybody is limiting technical discussion in any country. OTOH anti-blasphemy laws and hate speech laws are very common in many of the countries where we meet: Canada, European countries, even Brazil and Australia according to Wikipedia.

And since section 2.1 is about values, I don’t believe many of our attendees are "free speech at all costs” libertarians. If someone would like to combine IETF work with some extra-curricular protesting, I think that is covered as a non-goal in section 2.2

So what are we protecting our attendees from?

Yoav

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 04 May 2017 23:05:25 +0200

So, you will agree that we do a meeting in a venue were authorities may be watching what we talk in the meeting rooms and anything they don’t like means any kind of problems for the participants? For example, we may be discussing a way to increase privacy against public authorities traffic inspection.

I’m not referring to something outside the scope of our work. So, if someone want to participate in a protest, this will not be covered by the IETF venue selection criteria.

Regards,
Jordi

-----Mensaje original-----
De: Mtgvenue <[email-masked]> en nombre de Yoav Nir <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 4 de mayo de 2017, 20:20
Para: Eliot Lear <[email-masked]>
CC: <[email-masked]>, <[email-masked]>
Asunto: Re: [Mtgvenue] can we make an RFC for the venue selection process?

    
    Hi Jordi,

    

    

    

    Yoav

---

From: Eliot Lear <[email-masked]>
Date: Fri, 5 May 2017 08:13:29 +0200

Hi Jordi,

> I’m not referring to something outside the scope of our work. So, if someone want to participate in a protest, this will not be covered by the IETF venue selection criteria.

I think what you are suggesting is that there be a requirement along the
following lines:

>> There are no legal impediments to freely engaging in discussions
relating to the work of the IETF.

Have we ever even considered a venue where that was not the case?  Are
there such places?  I work in a global company that operates in nearly
every country in the world and I am not aware of such a place.  Even in
locales that have restrictions on encryption, while we might be limited
in what we can SELL, I don't think we've been limited in technical
conversations.  But perhaps others have different experiences (I'll
admit I haven't tested this in a number of countries myself).

And indeed if there were such a country, as we are going to add a
mandatory requirement around unfiltered access, would that not catch
this as well?

Eliot

---

From: Fred Baker <[email-masked]>
Date: Thu, 4 May 2017 23:51:12 -0700

> On May 4, 2017, at 11:13 PM, Eliot Lear <[email-masked]> wrote:
> 
> every country in the world and I am not aware of such a place.

I can tell you that I gave a talk once in a certain country, and mentioned cryptographic signatures as the most powerful tool for authentication/authorization and non-repudiation we know of. When the slide popped up, apparently there was a sudden change of translator, and following the talk they parked me in a room where nobody would be able to talk with me.

That was a while back, so the issue may no longer be a real one. But I know it happened once.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 05 May 2017 10:46:40 +0200

I’ve been in a similar situation around just 2-3 years ago …

I don’t think having that requirement, just in case, does any harm, on the contrary.

When I worked in https://tools.ietf.org/html/draft-palet-ietf-meeting-venue-selection-criteria-04, we had a debate on that, however I don’t recall who proposed that section and what was the discussion, it will be necessary to look into the mail archives … 

See section 2.3.  Freedom of Participation.

I think it will be interesting that some eyes different than mine, read again draft-palet-ietf-meeting-venue-selection-criteria-04 and the actual document, and check if there is something that was relevant in the first attempt to develop this work and we may be missing now, or even include a non-normative reference to that document in the actual one.

Regards,
Jordi

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 May 2017 16:59:11 -0400

> admit I haven't tested this in a number of countries myself).

At one point (late-1990s) the following things were true:
   a) Americans could not tell non-Americans how to *use* crypto.
      Some interpreted this to include explaining/writing test cases for
      verifying that it isn't failing.

   b) No Israeli could talk about encryption in Israel when non-"approved"
      persons were present.

I once flew to Zurich to meet with others to avoid (b).