Subject: FW: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 18 Jan 2006 22:36:49 +0100

Hi,

Here is the original announcement and the IETF URL.

Comments please !

Regards,
Jordi

------ Mensaje reenviado
De: "[email-masked]" <[email-masked]>
Responder a: "[email-masked]" <[email-masked]>
Fecha: Wed, 18 Jan 2006 15:50:01 -0500
Para: <[email-masked]>
Asunto: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

 Title  : IETF Meeting Venue Selection Criteria
 Author(s) : J. Palet
 Filename : draft-palet-ietf-meeting-venue-selection-criteria-04.txt
 Pages  : 18
 Date  : 2006-1-18
 
This document provides the IAD with technical and logistic criteria
   for selecting venues for IETF meetings.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-palet-ietf-meeting-venue-selection
-criteria-04.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
 "get draft-palet-ietf-meeting-venue-selection-criteria-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
 [email-masked].
In the body type:
 "FILE 
/internet-drafts/draft-palet-ietf-meeting-venue-selection-criteria-04.txt".
 
NOTE: The mail server at ietf.org can return the document in
 MIME-encoded form by using the "mpack" utility.  To use this
 feature, insert the command "ENCODING mime" before the "FILE"
 command.  To decode the response(s), you will need "munpack" or
 a MIME-compliant mail reader.  Different MIME-compliant mail readers
 exhibit different behavior, especially when dealing with
 "multipart" MIME messages (i.e. documents which have been split
 up into multiple messages), so check your local documentation on
 how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <[email-masked]>

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

------ Fin del mensaje reenviado

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

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.

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

---

From: Richard Shockey <[email-masked]>
Date: Thu, 19 Jan 2006 14:28:38 -0500

> Here is the original announcement and the IETF URL.

I'm assuming this is going to be Informational only and as such not 
formally binding on the IAOC on the Secretariat.

In fact that should be made explicit that nothing in this document 
should be considered formally binding on the IAOC or the Secretariat and 
that it only represents "useful suggestions".

This IMHO should have come directly out of the IAOC as the subject 
matter is directly within their oversight and charter.

What is the relationship of this document to the IAOC?

Frankly there is'nt much about this document I like. It's a classic 
example of the current IETF fashion for process over substance.

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 19 Jan 2006 20:01:25 -0000

Well Jordi,

That told you, didn't it?

Richard, do you speak for the Secretariat, for NeuStar, or for yourself?

Adrian

Richard Shockey <[email-masked]> might have said...

><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Jan 2006 22:35:57 +0200 (EET)

On Thu, 19 Jan 2006, Richard Shockey wrote:
> This IMHO should have come directly out of the IAOC as the subject matter is 
> directly within their oversight and charter.
>

I agree that these are valid points.  Spending cycles on this document 
isn't much use unless IAOC et al "buy in" into it.  Could someone from 
the "powers that be" say something on their thoughts on how venue 
selection criteria (etc.) should be developed?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Jan 2006 12:43:42 -0800

At 2:28 PM -0500 1/19/06, Richard Shockey wrote:
>It's a classic example of the current IETF fashion for process over substance.

Fully agree. What is the justification for this becoming an RFC?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 19 Jan 2006 16:01:32 -0600

From: "Paul Hoffman" <[email-masked]>
> Fully agree. What is the justification for this becoming an RFC?

Well, backing up slightly ...

How much of our process stuff (including existing BCPs) really needs to be 
published as an RFC?

Some does, I suppose, but "never changes" doesn't seem like the model we 
should search for on venue selection (the venue selection model used for the 
first 10 IETF meetings probably wouldn't have even booked us into 
Minneapolis, much less Adelaide!).

Having said this, I hope the IAOC does find this document useful input 
(because if they don't, people have sure been wasting zeros and ones on THIS 
list...

Thanks,

Spencer

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 20 Jan 2006 02:47:34 +0100

Hi Richard,

Thanks for your comments.

See my response below, in-line.

Regards,
Jordi

> De: Richard Shockey <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Thu, 19 Jan 2006 14:28:38 -0500
> Para: IETF list <[email-masked]>
> Asunto: Re: FW: I-D
> ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
> 

My personal view is that this should be an Informational document, as a
guideline of the selection criteria, as I already tried to describe in the
document.

There should be no difference between this and any other IETF document, in
that sense.

My opinion is that the binding is not related to the document type, but to
how we want to manage the meetings the next years.

The point here is simple: We really need a criteria. I've proposed several
venues since 2001, specially Madrid (but also Barcelona and others in Latin
America and Caribbean), and it was successfully evaluated by a secretariat
on-site visit. However, afterwards there was no "formal" rejection of the
venue and just a comment that "isn't located downtown". However, less than
one year after that, we had a meeting in San Diego, not in down town, and I
can ensure you with much much much much worst conditions that the Madrid
venue :-( (more distance to downtown, no public transport, more expensive,
etc., etc.).

Clearly, the old document that we have in the IETF site is insufficient and
the decision is so *subjective* (not accusing to anyone, just a fact), that
the situation is not fair neither acceptable.

I've complained during years, and I guess that was the reason Brian
Carpenter pointed to me suggesting that I should write the document (not
stating that Madrid should be the right venue), and I decided to take the
"risk".

It hasn't been an easy document, I will say even more difficult than a
technical spec, but I'm glad with the result. I think is a fair document,
that demonstrates also that the IETF is evolving, maturing and we are going
to have meetings in new places and be fair with all the contributors, and
that will also facilitate newcomers to actually start and keep contributing.

I'm also very glad because I've received tens of comments, many more than
what I can see, average, in the majority of other drafts.

I tried to accommodate my perception on the consensus of all those that
contributed, and the document evolved significantly from the first release
(11th July 2005), and I hope having achieved it.

I've also put completely aside, during this time, my own target to get a
meeting organized in Madrid or other locations that I've been proposing for
years, and even may be my own proposed venues will not match the criteria
now, but I don't care, that's being fair and objective and that's really a
must for this, if we want to get it working in an objective way.

> that it only represents "useful suggestions".

I think that's precisely against the original target of the document. As
said is only a guideline, but it must be followed in an objective way.

You can read in the document:
"Generally, this document does not present a strict list of "MUST"
   items.  Instead, it lists what needs to be evaluated, various
   alternative solutions, or combinations thereof, that may apply."

> matter is directly within their oversight and charter.

My understanding is that the IAOC is not engaged in the day-to-day work, and
that's the reason to have the IASA, the secretariat and the IAD. But they
need community driven guidelines to be able to follow as much as possible an
objective criteria.

You can read in the document:
"In the end, the IAD will make the final decision and will be accountable
   for it, and therefore he is responsible for applying the criteria
   defined in this document according to the hosting/sponsorship
   availability."

> What is the relationship of this document to the IAOC?

The same as for any other document which is related to the IAD, IASA, and/or
secretariat, nothing less, nothing more: The IAOC is responsible of
providing appropriate direction, oversight and approval.

But guess what, they also need some guidelines if we want an objective IAOC,
right ?

> example of the current IETF fashion for process over substance.

I don't really agree on that. The document is plenty of "juice" and
"substance". I've organized a few meetings, not so big as IETF, but some
times even for around 800-900 people and I can tell you that writing the
document has been an interesting exercise that also discovered me issues
that we generally aren't considering and need to be written down so the
process is fair, *not* because the process itself.

Now, all that said, I don't recall having heard comments from your side on
the document during all the process in any of the previous versions. It will
be very helpful that you provide them now, but please, try to be
constructive by commenting what exactly you dislike and even propose
specific text. I'm sure everyone will be happy to consider all the inputs.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 20 Jan 2006 02:53:17 +0100

Hi Paul,

I guess we can question ourselves the same way in many other documents ...

The importance of having documents is part of the IETF "working mode". Is
our way to say, here there is a consensus on this specific topic.

I guess is not my final decision if it will become and RFC or not, but it
will not be fair not following the same path for this document as for many
others.

That said, the original idea has been, since I was pointed out for editing
this document, to follow exactly the same process as with many other
documents, technical and administrative.

Regards,
Jordi

> De: Paul Hoffman <[email-masked]>
> Fecha: Thu, 19 Jan 2006 12:43:42 -0800
> Para: Richard Shockey <[email-masked]>, IETF list <[email-masked]>
> Asunto: Re: FW: I-D

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 20 Jan 2006 03:00:19 +0100

Hi Spencer,

I don't expect we have changes on the way we select venues for a few years.
Otherwise, the process for selecting them is not fair neither objective,
because a venue need to be selected (logistic reasons) at least 18-24 months
ahead. That means that lessons that we learn about what may be right or
wrong in the document will take more than 2 years to get debugged. Right now
we have already an experience of 20 years and we haven't changed too much
lots of things.

Moreover, we do changes in our documents, is not an issue if they are an RFC
or not.

And ... Being the document a guideline (may be BCP better than
Informational), is IAD the one that will take decisions about the venue
selection. I guess he will be smart enough to "correctly" apply the document
to the process. I've no doubt on that.

Regards,
Jordi

> De: Spencer Dawkins <[email-masked]>
> Fecha: Thu, 19 Jan 2006 16:01:32 -0600

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 19 Jan 2006 21:26:52 -0500

Speaking just for myself :

I think that there is a strong benefit to having an agreed upon set  
of parameters
for new meeting locations.

Having said that, this may not be appropriate for an RFC. Maybe it  
should be a "living document" on a web page
or wiki, as is being done / considered for mailing list anti-SPAM  
suggestions. Maybe a new class of
IETF document publication is needed.

Regards
Marshall Eubanks

On Jan 19, 2006, at 8:53 PM, JORDI PALET MARTINEZ wrote:

> 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: John C Klensin <[email-masked]>
Date: Thu, 19 Jan 2006 22:00:10 -0500

Jordi,

Unlike several others and their comments, there are significant
parts of this I find useful, at least in terms of identifying
issues that should be examined.  There are several other parts
of it with which I disagree.  And, ultimately, the presentation
of a list of suggestions without prioritization lowers its
utility considerably.  On the other hand, I doubt that consensus
even on the list of suggested principles is possible.  Consensus
about how they should be prioritized would be more difficult
yet, and consensus among those with significant experience
planning and running IETF meetings would certainly be no less
difficult.

The difficulty, it seems to me, is the combination between that
problem with claiming consensus and what can and should be done
with the document operationally.  It is just my opinion, but I
consider anything whose purpose is to tell the IAD, IAOC, or
IESG (or the IETF or IASA more generally) how to behave
procedurally or decide on things to be completely inappropriate
for publication as an independent submission RFC.  If others
agree, then the only way to get this published as an RFC is via
the IESG and some IETF consensus process.

One possibility is to just leave it as an I-D, updating it
periodically as needed, but keeping it out there as a
perspective that the IAD might consider.  That has certainly
been done with some IETF and meeting operational documents in
the past.  Another would be to pass it to the IAOC (see note
below) along with a suggestion that they establish a set of
periodically-updated IETF operating procedure notes and put this
(or a modified version of it) into that series.  Otherwise...
well, I just don't know, even independent of the aspects of it
with which I disagree.

I will try to find time to send you a list of particular topic
areas about which we appear to disagree, but I don't consider a
discussion of those specific topics to be appropriate or useful
on the IETF list unless the IESG decides that this document
should be an IETF topic (e.g., via a Last Call for BCP).

    john

(note: in both the document and some of your comments in the
last 24 hours, I think you've gotten the IAOC (the oversight
committee/ IASA decision body) and IASA (the whole
administrative operation in principle, but, in practice, just
the conceptual realization of the IAOC, the IAD (whom they
supervise), and the set of tasks and those who carry them out
that are supervised by the IAD and/or IAOC directly).)

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 20 Jan 2006 04:30:55 +0100

Hi John,

I understand your points and somehow agree on some of them.

I can try to establish a prioritization if that can help, and certainly I
will be happy to keep updating the document if at the end the decision is to
keep it in a web page, or just as a live I-D, or whatever else.

Regards,
Jordi

> De: John C Klensin <[email-masked]>
> Fecha: Thu, 19 Jan 2006 22:00:10 -0500
> Para: <[email-masked]>
> CC: "[email-masked]" <[email-masked]>
> Asunto: Re: I-D

---

From: Richard Shockey <[email-masked]>
Date: Thu, 19 Jan 2006 22:36:21 -0500

J
> There should be no difference between this and any other IETF document, in

But there are differences Informational is just that Informational and 
as such not binding on the parties as would be the Charter of the IAB 
IAOC, NOMCOM etc.

> the situation is not fair neither acceptable.

My position is this A. if it an'nt broke dont fix it and I do not see 
what is currently broken. B is is irrelevant whether the selection is 
subjective or not. All selections of this type are ultimately 
subjective. This class of IETF policy is the IMHO business of those to 
whom the NOMCOM has appointed to oversee such activity in this case the 
IAOC.

If the IAOC wishes to develop a criterion for site selections and then 
seek community support for such criterion then fine , that is the IETF 
way as I have come to understand it.

We appoint leadership for a reason ..to lead and make decisions. I dont 
like binding leadership with rules unless they serve a specific defined 
purpose necessary to the critical functioning of the organization. This 
is one of those decisions best left to those to whom we duly appoint to 
make such decisions.

In shorter words I believe in the concept of Management. The business of 
IETF Management is to Manage so we can get on with our business which is 
Internet Standards.

> stating that Madrid should be the right venue), and I decided to take the

Well Madrid indeed anywhere in Spain is the right venue for _anything_ 
:-) IMHO!!! I personally would not have any objection to having all 
future IETF meetings in Spain. Well maybe alternate the fall meetings in 
Portugal .. Oporto Lisbon come to mind.  Now I can see some objections 
to Ibiza. That might be a stretch...but at least once???

IMHO Brian Carpenter was seriously wrong in suggesting that an 
individual member of the community attempt to create such a policy 
document especially since we have just gone through a brutal process to 
set up a brand new management oversight committee to ultimately preform 
such functions, the IAOC.

Please dont get my wrong. You have obviously put much work into this and 
we should all be grateful for such contributions to the community. I 
just dont think it was necessary right now and even if there was a 
general consensus that it was necessary this is the proper task of the 
IAOC.

Brian should have known better.

> said is only a guideline, but it must be followed in an objective way.

NO on that I do disagree. That is why if this document is to become a 
RFC and I believe that it should not, it must be Informational.

> need community driven guidelines to be able to follow as much as possible an

The current set up is very new. I think it is a very very bad idea to 
impose policy criterion on these bodies until the dust settles. It has 
been a long hard struggle to get where we are at right now. Again if the 
IAOC wishes to consider such criterion then your draft is better edited 
there then presented to the community.

> specific text. I'm sure everyone will be happy to consider all the inputs.

I have commented on the document.

I dont think it should exist and certainly not as a BCP or Standards 
Track RFC.

1. Venue Selection Criterion is best left to the IAOC to determine 
policy. 2. Even if there was a need for community input the current IETF 
administrative structure is very new and some what fragile and we should 
not for the time being impose unwanted solutions on them they did not 
solicit support for.

--

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 20 Jan 2006 04:54:59 +0100

Hi Richard,

Just a short answer to avoid a long discussion on each of your replies ...

It is broken, anyone that has proposed to host an IETF meeting know it. What
you can read in the actual web page about hosting a meeting is not correct
in the reality, and can't be 100% subjective (yes there will be a decision
at the end, and that imply certain degree of subjectivity, but a criteria
helps to make it as much objective and fair as possible).

Remember my example, a real one: Venue A is proposed and is rejected because
reason "X". Some months later another venue "B" is hosting the IETF with
same problem "X" and even with a higher degree on the "X" problem compared
with venue "A". I don't thin you can still say isn't broken ! There are many
other examples and lot of people willing to host that has no starting point
to know if they can actually be a candidate venue or not.

Regards,
Jordi

> Fecha: Thu, 19 Jan 2006 22:36:21 -0500

---

From: Richard Shockey <[email-masked]>
Date: Thu, 19 Jan 2006 23:06:00 -0500

> planning and running IETF meetings would certainly be no less

Thank you John. As usual you have summarized many of my own feelings 
better than I have done.

> for publication as an independent submission RFC. 

My point exactly, again many thanks for your clarity.

> perspective that the IAD might consider. 

as Informational only.

--

---

From: John C Klensin <[email-masked]>
Date: Fri, 20 Jan 2006 02:05:24 -0500

--On Friday, 20 January, 2006 04:30 +0100 JORDI PALET MARTINEZ
<[email-masked]> wrote:

> I can try to establish a prioritization if that can help, and
> certainly I will be happy to keep updating the document if at
> the end the decision is to keep it in a web page, or just as a
> live I-D, or whatever else.

Just as long as you understand that it is going to be hard or
impossible to make it binding, or even strongly suggestive, on
the IAD via an IETF process without getting consensus that...

	(1) It is not clear that, with the IASA in place and
	specifically assigned the meeting site selection task,
	the IESG has the authority to ask for and evaluate...
	unless you propose, and succeed, in modifying BCP 101.
	
	(2) It seems unlikely to me that you would get that
	consensus if it were asked for, at least without many
	months of nit-picking.

Let me give one example on-list and then I'm going to drop back
out of the discussion.  At the end of the first paragraph of
section 2.2, you say "The IETF desires to meet in countries with
significant actual or potential participation."  The "potential"
part of that criterion has never been agreed upon.  We have
tended to go for actual participation, rather than trying to
create a presence where there are potential participants in the
hope of luring them in.  I can think of many reasons to not
change that.  You obviously either think we should or you
misunderstand the criteria that have been used for years.  I
suspect we could have a very long, and ultimately inconclusive,
discussion on this subject.  Indeed, I believe that once a few
people started enumerating what they saw as pros and cons, we
would discover that a very large portion of the IETF community
would have an opinion on the subject.  Interesting, but just not
very likely to be productive.  And, while that assertion sort of
leapt out at me, there are many others like it in the document.

I'd personally prefer to delegate this problem and discussion to
the IAOC, as BCP 101 appears to do, and let them sort it out
without an extended and detailed debate on the IETF list.   

Just my opinion, of course.

     john

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jan 2006 13:12:21 +0100

Hi,

Jordi developed this document largely at my request and with
frequent interaction with the IAD. Clearly, it's intended to be
of use to IASA in the selection of future meeting sites, and
equally of use to potential hosts in understanding the
requirements. Self-evidently, it is not intended to be a
binding document - this is quite clear in the text. But
I guarantee that it will be a very useful document; in fact
it's already been of use in discussion with potential hosts.

I appreciate Jordi's volunteer time spent on this document;
he didn't have to do it.

My expectation is that it will exist as a living document for
some time to come; we don't have the running code experience to
consider freezing it as an RFC yet.

So, could people please review it for errors and omissions?

      Brian

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Fri, 20 Jan 2006 07:30:47 -0800 (PST)

> selection criteria (etc.) should be developed?

I'm not sure that I constitute a "power" (more likely just another
slave to process) but I've added review of this document to the next
IAOC Agenda and we will get Jordi our comments shortly there after.

- lel

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Jan 2006 11:30:34 -0500

> So, could people please review it for errors and omissions?

My biggest concern is in sections "2.3.  Freedom of Participation"
and "2.5.  Attendance Limitation and Visas", in that I'm not sure
how realistic they are.  Without getting overly into politics (let's
please not), I think they reflect a somewhat naïve view of some of
the political realities.  Specifically...

    Meetings should not be held in countries where some attendees could
    be disallowed entry or where freedom of speech is not guaranteed for
    all participants.

The United States certainly cannot be assumed to allow ALL attendees
entry.  It's well known that we have lists of people we won't allow
in, and lest we think that's limited to the sort of nasty folk who
wouldn't be attending the IETF anyway, I'll point out that a plane
carrying Yusuf Islam -- the singer formerly known as Cat Stevens --
was landed in Maine so that the singer could be removed and sent home
before the plane continued to New York.  Individuals do get on these
lists unreasonably, or by mistake.

Ignoring the issue of individuals, whole groups may have difficulty.
The US has a list of "restricted countries", which includes Iran and
North Korea, and a longer list of countries to which exports of software
or technology are controlled (this list includes Russia and China,
for example).  There's certainly no guarantee at any time that attendees
from these countries won't have a difficult time getting visas, or might
not be able to get them at all.

As to freedom of speech:  We could argue about the reality of that
for a while, but even apart from that, our government has made it
clear that it considers those constitutional rights to apply to US
citizens only, and not to foreign nationals who may be visiting.

OK, all that said, I don't think the US is a bad country in which to
have IETF meetings.  Which is, really, my point: I think the text
needs to be changed to better express the intent, which is that we
want to avoid countries that are unduly restrictive, without trying
to limit things to utopian -- and non-existent -- lands of complete
freedom.

--
Barry Leiba  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

---

From: [email-masked]
Date: Fri, 20 Jan 2006 15:28:36 +0000

> helps to make it as much objective and fair as possible).

	having hosted an IETF, i'll make the comment that i -really- wanted a
document like this as a "handbook" of things to expect.  But that was back in the
day...  I wrote up some notes and passed them on to the next local host.  a few 
mtgs later, Mark Prior ran into some of the same concerns when he hosted an IETF.
and so a few of us who -had- hosted IETF mtgs got together and wrote up an ID on
hosting requirements.  That draft went 'round the IESG a couple times and then died
a quiet death.   And rightly so.  Such a document is not w/in the IETF remit of defining
Internet Protocols.   So i really understand why you too, would like to see something
like this be in the IETF archives.... but it is NOT in the remit of the IETF as I understand
it.  However, the IETF of today is clearly NOT the IETF i spent time with, so things
could have changed.

--bill

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 22 Jan 2006 15:42:30 -0400

Hi Barry,

Thanks a lot for your inputs.

I think this point is extremely important and we really need a clear
multi-national position on that, not just from a lot of participants of a
few countries, unless we want to restrict the participation of only
nationals from those countries.

See my reply, below-in line.

Regards,
Jordi

> De: Barry Leiba <[email-masked]>
> Responder a: "[email-masked]" <[email-masked]>
> Fecha: Fri, 20 Jan 2006 11:30:34 -0500
> Para: "[email-masked]" <[email-masked]>
> CC: <[email-masked]>
> Asunto: Re: I-D 

It think is fine, of course, don't having as mandatory for a country to
allow to come for an IETF meeting somebody that did something which is
against the law (being a criminal, terrorist or whatever), but not just
because he/she has this or that way of thinking or is national for this or
that country (not to name political, religious, sexual or any kind
opinions).

IETF is an open institution, which don't care about good or bad political
decisions of countries or institutions; we just care about the way we want
the world to do technology to be interoperable for all.

Consequently, if a country don't allow some of us, some contributors or
people willing to contribute, to attend our meetings, that country is
against our goals, and is not good for IETF and is then not good for hosting
an IETF meeting.

I also understand, and that's the complete feeling behind the document, that
we may have no other alternative that hosting the meeting in such country,
but that may be the consequence of not having a better venue, or having
venues which are even more restrictive for a bigger group of contributors or
possible contributors.

The consequence for the IAD from the reading of this document in this
regards, should be like making sure that if better opportunities are
available, are actually used. If the result is that less meetings are being
hosted in certain countries, that's perfectly fair, because the overall
participation will be wider.

If some contributors don't wish to go to other countries, that's a personal
decision and could show a political view from their side, instead of a real
non-political interest in contributing to the work. And as such that is
against IETF goals of a wider participation; such type of "pressure" for the
IAD to move back to certain countries must never be accepted.

> not be able to get them at all.

I'm not saying either that the meetings should be held on those countries
either, if they don't respect in a reciprocal way, that anyone can attend
the meeting.

There are lot's of other options, and if that means including a dozen of
countries in the world, even if they are big countries, what is the problem
?

As said, anyway, this is only in case we have no other better choices.

I think the difference is that I'm not saying "MUST not be held". I'm using
a should.

> citizens only, and not to foreign nationals who may be visiting.

Well, I didn't knew that, and I'm very sorry and sad to heard it, clearly is
a terrible statement coming for a government, and that's very negative, in
my *very personal* opinion, for the government and the citizens that accept
that, and becomes then evident for me that this country is not a good one
for IETF. May be this is something also happening in my own country and I
didn't knew it, but if that's the case (I doubt it), I don't care and I will
also have the same opinion from my *own* country, is not good and is
unacceptable.

If it was my personal decision, I will even make MUST for that specific
case, such as "Meetings MUST NOT be held in countries which don't respect
the freedom of speech for foreigners". :-(

> to limit things to utopian -- and non-existent -- lands of complete

As said, I'm not using a MUST, but a SHOULD.

As a consequence if there is a better choice for our meetings, we should opt
for that one. If it means having less meetings in certain countries, that's
perfectly fine and must be that way.