Subject: Travel/Attendees list FAQ

From: "George, Wes" <[email-masked]>
Date: Wed, 7 Dec 2011 09:09:26 -0500

Based on the discussion on the 82 attendees list, I put together a draft that provides a list of common questions (but not necessarily answers) that people ask when preparing to travel to a meeting. As the draft states, this is an attempt to provide a list of ideas for folks who can contribute to a wiki or host site (because they're familiar with the area), to help them ensure completeness of the information that they provide. It doesn't compel anyone (host, IETF, secretariat, etc) to do anything, merely makes recommendations.
I got some feedback on the -00 version from folks on the 82-attendees list, and I've updated the draft with an -01 version based on that feedback. I am now expanding the audience to the larger list so that I can get additional feedback. Please have a look and send comments my way.

I'm also open to suggestions as to the appropriate publication track for this document, whether I should look to have it sponsored as a GenArea doc or simply put it forward as an individual submission.

http://tools.ietf.org/html/draft-george-travel-faq

Thanks,

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 07 Dec 2011 06:27:54 -0800

On 12/7/2011 6:09 AM, George, Wes wrote:
> I'm also open to suggestions as to the appropriate publication track for
> thisdocument, whether I should look to have it sponsored as a GenArea doc or simply>
> put it forward as an individual submission.

> http://tools.ietf.org/html/draft-george-travel-faq

I suggest that this be processed as an individual submission.  It will still get 
IETF review but I believe it does not require the level of active consensus by a 
working group (pseudo or otherwise) that a typical technical specification does.

However I suggest that the document cast itself as a snapshot of an on-going 
documentation process, with the "master" copy being an IETF Wiki; the document 
should contain a point to the wiki.

I'll also suggest that there be an on-going mailing list for discussing meeting 
logistics issues, rather than a different mailing list for each meeting. 
(ietf-meeting?)

The current contents -- a template of information to be developed -- looks quite 
good.  But it can't be "complete", and the definition of "complete" is likely to 
change frequently.  That's a perfect candidate for a wiki effort.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "George, Wes" <[email-masked]>
Date: Wed, 7 Dec 2011 09:40:49 -0500

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Wednesday, December 07, 2011 9:28 AM
> To: George, Wes
> Cc: IETF Discussion
> Subject: Re: Travel/Attendees list FAQ
>
>
[WEG] There is currently a pointer to the wiki, but I'll have to think on how to update the text to make this distinction about how updates are managed. I'd like to hope that we can get to something quasi-complete in terms of the questions, since they should be relatively static and the answers are what changes from meeting to meeting and are stored in the wiki, with the idea that updates to this document could be handled through the draft process periodically (similar to other docs like the Tao).
> logistics issues, rather than a different mailing list for each
[WEG] I think because you have different attendees for each meeting that this might be problematic. I didn't miss the email chatter for the last IETF meeting that I didn't attend, and in fact, the whole point of this draft is to try to cut down on said chatter. Perhaps the way to manage this is to have two lists - an IETF-meeting list, and then an xxattendees list, and then people interested in higher-level meeting logistics (not specific to one meeting) can manually subscribe to the IETF-meeting list, and the xxattendees list itself is simply subscribed to the ietf-meeting list for the duration of its relevant period, and then unsubscribed afterwards (or vice versa).

Thanks
Wes George

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 07 Dec 2011 06:53:55 -0800

> change frequently.  That's a perfect candidate for a wiki effort.

Are you saying that we need a Wiki for the template that will be used to fill a
Wiki?

There is a finite number of things that an attendee needs - transportation,
visa, lodging, food, etc...  I do not think that there will be a lot of changes
after few iterations of the draft, and I am OK with publishing a new RFC when
teleportation devices will be available.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 7 Dec 2011 10:11:58 -0500

What is the value in publishing a living document as an RFC (which inherently a static, archival document)?  Wouldn't it make more sense to convert the contents of this document to a Wiki page that we could jointly edit and maintain going forward?

Margaret

On Dec 7, 2011, at 9:27 AM, Dave CROCKER wrote:

> I suggest that this be processed as an individual submission.  It will still get IETF review but I believe it does not require the level of active consensus by a working group (pseudo or otherwise) that a typical technical specification does.
> 
> However I suggest that the document cast itself as a snapshot of an on-going documentation process, with the "master" copy being an IETF Wiki; the document should contain a point to the wiki.
> 
> I'll also suggest that there be an on-going mailing list for discussing meeting logistics issues, rather than a different mailing list for each meeting. (ietf-meeting?)
> 
> The current contents -- a template of information to be developed -- looks quite good.  But it can't be "complete", and the definition of "complete" is likely to change frequently.  That's a perfect candidate for a wiki effort.
> 
> d/
> -- 
> 
>  Dave Crocker
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 07 Dec 2011 07:20:25 -0800

On 12/7/2011 6:40 AM, George, Wes wrote:
>> However I suggest that the document cast itself as a snapshot of an on-
>> going documentation process, with the "master" copy being an IETF Wiki; the
>> document should contain a point to the wiki.
> [WEG] There is currently a pointer to the wiki, but I'll have to think on
> how

apologies for my phrasing.  yes, the current wiki is fine, as a venue.

what I mean to focus on is the relationship between the wiki and the RFC.  I'm
suggesting that the RFC be classed as a snapshot of the wiki.  I am suggesting
that the RFC have language that makes this explicit.

> to update the text to make this distinction about how updates are managed.

Right.  My suggestion:

      Whenever there is an 'interesting' set of changes and the changes appear to
be stable is when the RFC should be revised.  This emphasizes that the wiki is
where the real work on the template is done.

> I'd like to hope that we can get to something quasi-complete in terms of the
> questions, since they should be relatively static and the answers are what

"relatively", hopefully.

>> I'll also suggest that there be an on-going mailing list for discussing
...
> [WEG] I think because you have different attendees for each meeting that
> this might be problematic. I didn't miss the email chatter for the last IETF
> meeting that I didn't attend, and in fact, the whole point of this draft is
> to try to cut down on said chatter. Perhaps the way to manage this is to
> have two lists - an IETF-meeting list, and then an xxattendees list, and
> then
...

I fear this issue does not have a clean solution.  With two lists, you'll get
cross posting or divergent threads.

I think I'll withdraw my suggestion for an additional mailing list...

> On 12/7/2011 7:11 AM, Margaret Wasserman wrote:
>> What is the value in publishing a living document as an RFC (which
>> inherently a static, archival document)?

Certainly a fair question.

It's probably not essential, but it seems to me like a good idea to get a basic 
consensus reference point periodically.

d/
-- 

   Dave Crocker

---

From: Bob Hinden <[email-masked]>
Date: Wed, 7 Dec 2011 08:47:10 -0800

> What is the value in publishing a living document as an RFC (which inherently a static, archival document)?  Wouldn't it make more sense to convert the contents of this document to a Wiki page that…

+1

I think it's important that this be dynamic and easy to change.  

Bob

---

From: "George, Wes" <[email-masked]>
Date: Wed, 7 Dec 2011 12:28:23 -0500

> inherently a static, archival document)?  Wouldn't it make more sense
> to convert the contents of this document to a Wiki page that we could
> jointly edit and maintain going forward?
>
> +1
>

[WEG] I think that we're already off in the weeds based on an incorrect assumption, so I'd like to clarify before we get too far along with this. This is a list of the *questions* because they do not change much from one meeting to the next. The document already recommends that the *answers* which will be different for every venue be kept in a place where they are more easily updated.

>From the abstract: "This document attempts to provide a list of the common Frequently
   Asked Questions (FAQs) ... if
   they wish to pre-populate answers to some or all of these questions
   either in the IETF Wiki or a meeting-specific site, they have a
   reasonably complete list of ideas to draw from."

I'm going to take a crack at refining this text a bit based on Dave's prior feedback, but if I'm missing something as to why you're saying "don't put this in an RFC because it changes too much" please clarify.

Thanks
Wes George

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 07 Dec 2011 09:36:01 -0800

On 12/7/2011 9:28 AM, George, Wes wrote:
> This is a list of the*questions*  because they do not change much from one meeting to the next. The document already recommends that the*answers*  which will be different for every venue be kept in a place where they are more easily updated.

I think questions will get revised -- mostly with additional questions -- over 
time.  This is certainly easiest as a wiki.  I suspect that site-specific issues 
could well mean some different questions for each event.

But note that there needs to be a different wiki for each IETF meeting.  That 
includes a different URL.  We should preserve each meeting's wiki as part of the 
meeting archive, rather than replacing one meeting's content with the next.

d/
-- 

   Dave Crocker

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Dec 2011 12:48:13 -0500

On Wed, Dec 07, 2011 at 09:36:01AM -0800, Dave CROCKER wrote:

> But note that there needs to be a different wiki for each IETF
> meeting.  That includes a different URL.  We should preserve each
> meeting's wiki as part of the meeting archive, rather than replacing
> one meeting's content with the next.

Wikis usually have a mechanism to look at old content.  Wouldn't that
be more practical than preserving an ever-increasing number of wikis
of what is, by its very nature, not really stable information?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 07 Dec 2011 11:51:59 -0600

> of what is, by its very nature, not really stable information?

The per-meeting Wiki model has been used by SIPit for years now, and 
it's immensely useful. In that case it's also private (only visible to 
the registered meeting attendees), which allows for a bit more freedom 
to use it for coordinating logistics, outside events and the like. For 
each meeting, a 'template' wiki site is copied to create the new meeting 
Wiki, so that there is a structure in place and page templates ready to 
be used for new content.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 07 Dec 2011 10:15:37 -0800

> of what is, by its very nature, not really stable information?

1.  Oh.  No, I had not thought of that very interesting possibility.

2.  It probably won't give the right result or at least not conveniently.

I was/am thinking in terms of being able to read what was in force for a 
particular meeting.  Wikis tend to be changed incrementally and without any 
checkpoingts for "versions".  Hence, using the history mechanism is likely to 
require wandering through a variety of versions.

Offhand, I think the wiki history mechanism is extremely useful for 
understanding incremental evolution, rather than massive change.  For each 
meeting, much or most of the content will change.  It really does make it a new 
database at that point, IMO.

d/

-- 

   Dave Crocker

---

From: Bob Hinden <[email-masked]>
Date: Wed, 7 Dec 2011 10:41:20 -0800

Wes,

> [WEG] I think that we're already off in the weeds based on an incorrect assumption, so I'd like to clarify before we get too far along with this. This is a list of the *questions* because they do n…

While I agree that the questions won't change as often as the answers, it will likely change.  We have come a long way from just asking how many cookies there will be.  

Also, if it gets published as an RFC, it is going to be viewed as a "specification".  I think it's best to avoid that and just have a wiki.    I would be surprised if this topic continues to be as active area of discussion in the future, making it unlikely that there would be new RFCs published.  

Further, is this something we really want in the historical record.  

Bob

---

From: Ole Jacobsen <[email-masked]>
Date: Wed, 7 Dec 2011 11:33:13 -0800 (PST)

The flip side of this argument is that it could be viewed as a helpful 
guide for the hosts/sponsors at any given venue. ("This is the kind of 
information you should provide.")

At APRICOT, we've developed an "Ops Manual"[1] that covers everything 
from room setup to "no kareoke" at the social event. I am not saying 
that our document needs to be an RFC, but we don't have a lot of 
alternative ways to publish things that can be quickly retrieved, 
printed off and so on.

[1] http://www.apricot.net/docs/APRICOT-Op-Man.pdf

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj
Skype: organdemo

On Wed, 7 Dec 2011, Bob Hinden wrote:

> 
> While I agree that the questions won't change as often as the 
> answers, it will likely change.  We have come a long way from just 
> asking how many cookies there will be.
> 
> Also, if it gets published as an RFC, it is going to be viewed as a 
> "specification".  I think it's best to avoid that and just have a 
> wiki.  I would be surprised if this topic continues to be as active 
> area of discussion in the future, making it unlikely that there 
> would be new RFCs published.
>

---

From: Melinda Shore <[email-masked]>
Date: Wed, 07 Dec 2011 10:44:59 -0900

> information you should provide.")

I don't see any reason that couldn't be wikified, either.

I am not sure that there needs to be a document describing what
should be made available, other than as a tool to structure the
discussion.  I'm also pretty sure (not 100%, but somewhere north
of 50%) that there really aren't any serious archival requirements
for the material under discussion.

We're not the ITU-T, we're not ETSI, etc - not everything needs to
be formalized.

Melinda

---

From: Ole Jacobsen <[email-masked]>
Date: Wed, 7 Dec 2011 11:51:39 -0800 (PST)

I am not arguing against the wiki, I am just saying that there is 
value in having a single "file", or "document", or maybe "checklist"
that can be retrieved (and printed) too. And we have lots of docs
that could hardly be described as "formal".

But a template for the required information would indeed be useful.

Ole

Ole J. Jacobsen

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 07 Dec 2011 11:54:46 -0800

On 12/7/2011 11:44 AM, Melinda Shore wrote:
> I'm also pretty sure (not 100%, but somewhere north

formal requirements, perhaps not.

however the collection of information that is provided for a meeting constitutes 
an interesting database for later reference.

if storage were expensive, perhaps not, but it ain't.

d/
-- 

   Dave Crocker

---

From: Melinda Shore <[email-masked]>
Date: Wed, 07 Dec 2011 11:08:35 -0900

> But a template for the required information would indeed be useful.

I guess I'm not seeing anything here that looks to me like
requirements, or anything here that can't be satisfied with
something totally open, like a wiki.

This whole business of trying to formalize this strikes me as
rather of a piece with non-"Bar" non-"BOFs" and ossification
of IETF processes.  I think it's great that Wes put together
a proposal and I hope that it's seen as a starting point for
a wiki or some such rather than as yet something else that
needs an editor and needs an approval process and that isn't
as lightweight and responsive as something like an attendees
info sheet should be.

Melinda

---

From: Warren Kumari <[email-masked]>
Date: Wed, 7 Dec 2011 15:11:09 -0500

> information you should provide.")

+ lots...

I work for a company that is sponsoring an upcoming meeting.

Most of the organization is being done by folk who have never attended an IETF meeting (but some of them will be coming to Paris to get a feel for things). 
This document has been hugely useful (oddly enough we were talking about just how useful today) to help them understand the general feel, the sorts of things to pay attention to, what information is needed, the pain associated with trains (:-P), food considerations, etc.

> [1] http://www.apricot.net/docs/APRICOT-Op-Man.pdf

Something like this tailored to the IETF would be awesome.

The organizers at many of the sponsors are not IETF participant / attendees and having useful reference / background material would we really good for them -- a single document like the APRICOT-Op-Man or an RFC, self contained (and printable), in a single voice will be much better understood than a whole collections of pages with various voices....

I often (usually?) disagree with Wes, but think that this draft is *really* useful and is worth publishing...

W

---

From: "George, Wes" <[email-masked]>
Date: Wed, 7 Dec 2011 15:43:57 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Melinda Shore

> I think it's great that Wes put together

[WEG] For my part, since I've gone to the trouble of "draftifying" this, I plan to get my document to a point where I feel that it's reasonably complete (ie I'm not receiving any additional feedback on items that are missing) and publish via the individual submission process. As with most other RFCs, what folks choose to do with the document once it's published (use as a wiki/info website template, summarily ignore, etc) is really up to them. It was intended to be a (hopefully helpful) tool, and my best-case result would be that it is provided with the information that we typically give to hosts to assist them in hosting an IETF.
However, I purposely left any sort of formal direction to IAOC or the secretariat out of this document, at least partially because I think that this is simply one example of a recurring problem about how IETF should manage non-static info (cf previous discussions about official per-RFC wiki entries, etc), and I didn't want to have the solution to the generic problem be blocking for this specific example.

In the meantime, my hunch all along has been that if for some reason the baseline information necessary (not the answers to the questions) changed enough that this document was in need of significant updates, someone (maybe me if I'm still involved) would simply write an update to it.

Wes George

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Dec 2011 12:55:44 -0800

OK, so now we have a data point from someone who is the target customer for this work. It sounds like they want a stable "document" (with quotes).

Dave started the thread towards "wiki", but didn't define if "wiki" meant "anyone in the IETF community could edit it" or "a non-editable web page that exists in the IETF Wiki structure". I propose something much more like the latter, and definitely not the former, so that meeting sponsors (the target customer) have something mostly stable to look at.

--Paul Hoffman

---

From: Ole Jacobsen <[email-masked]>
Date: Wed, 7 Dec 2011 13:12:05 -0800 (PST)

Yes,

I would be happy to say to a host/sponsor: "We have a baseline 
document X, it's been out there for a while and some additions,
suggestions etc can be found at Wiki W. Please have a look at
X and W, and see example E for how host foo did this at IETF
nn."

Ole

Ole J. Jacobsen

On Wed, 7 Dec 2011, Paul Hoffman wrote:

> OK, so now we have a data point from someone who is the target 
> customer for this work. It sounds like they want a stable "document" 
> (with quotes).
> 
> Dave started the thread towards "wiki", but didn't define if "wiki" 
> meant "anyone in the IETF community could edit it" or "a 
> non-editable web page that exists in the IETF Wiki structure". I 
> propose something much more like the latter, and definitely not the 
> former, so that meeting sponsors (the target customer) have 
> something mostly stable to look at.
> 
> --Paul Hoffman
> 
>

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 07 Dec 2011 18:49:19 -0800

> X and W, and see example E for how host foo did this at IETF

Actually, I meant wiki according to its classic, collaborative meaning:

    <http://en.wikipedia.org/wiki/Wiki>

What you folks are describing is a web page, not really a wiki.

The problem with designing this for use by a host is when we have no host.  It 
also makes the host the gatekeeper of information.  As we've seen quite often, 
good information comes from all over the community.  We should take advantage of 
that by allowing anyone to add the information.

Access to IETF wikis already requires a login.  I would expect a Venue 
Information Exchange Wiki (VIEW...) to be subject to the same requirement.

The template described in the I-D, gives excellent structure to the wiki.

I believe it would not be not an onerous burden on the Secretariat to establish 
a new wiki, according to the standardized template, for each meeting.  After 
that, whoever has knowledge for that meeting can populate the database.

d/
-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Dec 2011 01:01:39 -0500

--On Wednesday, December 07, 2011 10:41 -0800 Bob Hinden
<[email-masked]> wrote:

>...
> Also, if it gets published as an RFC, it is going to be viewed
> as a "specification".  I think it's best to avoid that and
> just have a wiki.    I would be surprised if this topic
> continues to be as active area of discussion in the future,
> making it unlikely that there would be new RFCs published. 

Oddly, although I think some clarifying language about intent
and the difference between preferences and requirements would be
in order, I think "specification" --of information that the IETF
hoped that a sponsor, local host, the secretariat, or someone
else would provide or help the community to obtain-- is entirely
in order.  I see little, if anything, on his list that is not
asked for, in one form or another, at almost every meeting
(unless we have been to the location already, and sometimes
then).  I see little on that list that hasn't been routinely
supplied at least a few times in the past at prior IETF meetings
or at other international meetings I attend.   By and large,
when things are left out, that is the result of accidental
omission rather than intention... and the accidental omissions
cause unnecessary problems or concerns.  By organizing the
questions, as Wes is doing, we can eliminate some of those
difficulties with (at least if we are clear about intent) little
marginal cost to anyone.  

I do note something that Wes, by only listing the questions,
omits, which is that there are several of these questions to
which "not really relevant here" or "we don't have a clue" would
be perfectly reasonable answers... and would actually provide
information.

If, as you suggest, the topic is not likely to be discussed
regularly --presumably, given this community, because the list
of questions is fairly stable-- to me that reinforces the
desirability of publishing the list in readily-accessible (and,
as others have pointed out, compact and printable) form rather
than making it undesirable.

> Further, is this something we really want in the historical

Why not? If there is anything on the list that can be construed
as "we think your city is a bad place" or "we think hosts and
facilities are out to screw us", it should be revised so those
inferences are not possible.  Actually, that is another
advantage of having a standard, published, list of questions: it
demonstrates that we ask the same questions of everyone rather
than singling out particular locations for suspicion.  If hosts,
facilities, or local people think some of them just aren't
applicable, they simply note that and move on (again, a little
more introductory text might be in order, but I think the
principle is just fine).

best,
   john

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Dec 2011 08:00:09 -0800

> What you folks are describing is a web page, not really a wiki.

Exactly, and that is appropriate for something whose primary target is organizations that are giving large amounts of money and time to the IETF. A "collaborative page" can easily go sideways with contributors who don't understand the parameters of what is meant to be there. In many cases such as WGs, such sideways motion is fine; for a page whose audience are often people who don't know about the IETF but are tasked with deciding whether or not to give us significant financial support.

--Paul Hoffman

---

From: David Morris <[email-masked]>
Date: Thu, 8 Dec 2011 08:31:54 -0800 (PST)

On Thu, 8 Dec 2011, Paul Hoffman wrote:

> Exactly, and that is appropriate for something whose primary target is 
> organizations that are giving large amounts of money and time to the 
> IETF. A "collaborative page" can easily go sideways with contributors 
> who don't understand the parameters of what is meant to be there. In 
> many cases such as WGs, such sideways motion is fine; for a page whose 
> audience are often people who don't know about the IETF but are tasked 
> with deciding whether or not to give us significant financial support.

Perhaps, but in a wiki context repair is easy as any reasonable wiki
software will provide a history.  In addition, at least one proposal
was that editing be limited to some form of registered users which
should also mean that abuse can be mitigated.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Dec 2011 08:36:01 -0800

On Dec 8, 2011, at 8:31 AM, David Morris wrote:

> software will provide a history.  

What is the greater additional value of having to have someone who watches the wiki and reverts changes over that same person being listed on the static page as "if you have questions or suggestions about this page, please send mail to <real human's name>"?

> In addition, at least one proposal

Please note that I wasn't talking about abuse, I was talking about misunderstanding. The latter seems very likely in our crowd, given our propensity to mistake implementations for requirements, for example.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Thu, 8 Dec 2011 11:38:09 -0500

On Dec 8, 2011, at 11:00 AM, Paul Hoffman wrote:

> Exactly, and that is appropriate for something whose primary target is organizations that are giving large amounts of money and time to the IETF. A "collaborative page" can easily go sideways with contributors who don't understand the parameters of what is meant to be there.

Yes, and who have very little incentive to add stuff -- for example, look at the WG Chairs wiki ( http://wiki.tools.ietf.org/group/wgchairs/ )-- the subtitle is: "Everything a WG Chair Needs to Know but Was Afraid to Ask" . This site is far from useful[0], and hasn't been kept up to date (mnot made some changes ~ 6months ago, 22months ago Marc changed some email addresses, 2 years ago Tony changed a URL or two, most of the content is 5 years old). It is *far* from "everything a WG Chair needs to Know" -- something like this aimed at the event folk / organizers at a sponsor is not going to reflect well on the IETF and is not going to help lead to a successful meeting.

If we ended up with the opposite problem (everyone editing), things would be much much worse -- anyone reading this would assume that we are a bunch of childish, blithering idiots -- go read some previous Attendees lists and sample random threads (the "Hilton clock" thread: http://www.ietf.org/mail-archive/web/80attendees/current/msg00271.html , the "CD is a chocolate?" thread, the infamous Maastricht train threads) -- these are the sorts of things that folk might add the the Wiki -- it this really the image we want to be projecting?

Wiki's are a great idea, *for some things*, but (IMO) this is not one of them.

W

[0]: Yes, I *know* it's a wiki and I can / should go edit it myself, but, well....

> In many cases such as WGs, such sideways motion is fine; for a page whose audience are often people who don't know about the IETF but are tasked with deciding whether or not to give us significant financial support.
> 
> --Paul Hoffman
>

---

From: David Morris <[email-masked]>
Date: Thu, 8 Dec 2011 08:46:04 -0800 (PST)

On Thu, 8 Dec 2011, Paul Hoffman wrote:

> What is the greater additional value of having to have someone who 
> watches the wiki and reverts changes over that same person being listed 
> on the static page as "if you have questions or suggestions about this 
> page, please send mail to <real human's name>"?

Difference is whether the community is better served by a fail open or
fail closed approach. I don't believe active watching is required. I think
the value of informed contributions without waiting for the real human
to review and provide the update. Even active review is less henious in
terms of work load in a context where we expect updates, even errors,
to be contributed with best intentions.

A Hybrid is another possiblity ... a 'fact' page with limited edit
could be the parent of the community edited content. Certainly not
an expensive experiment?

> Please note that I wasn't talking about abuse, I was talking about 
> misunderstanding. The latter seems very likely in our crowd, given our 
> propensity to mistake implementations for requirements, for example.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 08 Dec 2011 09:16:32 -0800

On 12/8/2011 8:00 AM, Paul Hoffman wrote:
 > A "collaborative page" can easily go sideways with contributors who don't
 > understand the parameters of what is meant to be there

In the IETF?  Folks can misunderstand or getting carried away or both?

tsk, tsk.

But seriously, my general impression is that the comments and suggestion people 
post on the venue mailing list are typically pretty good.  So serious 
misinformation or misbehavior seem less likely than for a controversial working 
group, IMO.

We can rely on group review and reaction, for catching the problem you cite.

On 12/8/2011 8:36 AM, Paul Hoffman wrote:
> What is the greater additional value of having to have someone who watches
> the wiki and reverts changes over that same person being listed on the static
> page as "if you have questions or suggestions about this page, please send
> mail to<real human's name>"?

Huge.

They are fundamentally different models in terms of effort and responsiveness.

A reactive model -- watch and fix -- is much less effort, for a well-functioning
wiki than is a proactive model with highly constrained access.  The monitor is 
not in the critical path; they are not a gatekeeper who slows things down.

The reactive model distributes work among those motivated to perform it, rather
than concentrating everything onto the one or few people in charge.

If the reactive model fails, it is usually due to a dysfunctional group, in
which case the model isn't the problem.

d/

-- 

   Dave Crocker

---

From: Eric Burger <[email-masked]>
Date: Mon, 12 Dec 2011 11:08:05 -0500

+1,000,000

The argument that an RFC, retrieved from the web, is more accessible than a web page or wiki, retrieved from the web, does not reflect reality.

The argument that if the questions do not change much from venue to venue needs to be an RFC, and not a web page or wiki, does not hold water. RFCs are supposed to NEVER change. That is why we still have RFC 1000, 2000, 3000 available. Do we really need 6 RFCs covering "what makes a good host", because we keep thinking of new items or to fix old ones?

The argument that we need an RFC or twelve to show potential hosts, instead of a "how to host an IETF" web page is beyond wrong. One thing that keeps coming up is the people who do the on-the-ground hosting of IETFs are not people who attend IETFs. They are the "party planners," hotel coordinators, swag printers, etc. For them an RFC is entirely alien. I would be amazed if they (1) could find an RFC and (2) if they read beyond the 1.5 pages of IETF Trust boiler plate. Conversely, these people are totally used to going to a web page to pick up tips or requirements for hosting.

In theory I could be swayed for making this data available as a managed web page, but in practice it will get done if it is a wiki. Instead of 16 messages on why we should or should not publish an RFC, which most would agree would be obsolete before it gets published, we could have had 12 entries in a wiki. With Wes' work as a seed, we would be done by now.