Subject: Re: Colloquial language [Re: Last Call:<draft-hoffman-tao4677bis-15.txt> (The Tao of IETF: A Novice'sGuide to the Internet Engineering Task Force) to Informational RFC]

From: t.p. <[email-masked]>
Date: Fri, 1 Jun 2012 09:06:36 +0100

---- Original Message -----
From: "Ben Niven-Jenkins" <[email-masked]>
To: "Ole Jacobsen" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 31, 2012 11:36 PM
On 31 May 2012, at 09:16, Ole Jacobsen wrote:
> Sounds like a difficult thing to do with any kind of predictable or
> measurable outcome, although it might be fun to ask the Brits if they
> understand everything the Americans are saying and vice versa :-)

I don't really have any issues understanding American English but I'm
regularly gobsmacked by how many North Americans struggle to understand
some things that I say :-)

<tp>
It's called irony; it got left behind on the beach, when the Pilgrim
Fathers crossed the pond.

On the other hand, it could just be that what you say <>is<> cricket.
Which would also be perfectly comprehensible to the Indian audience,
alluded to earlier (and to the remainder of the English speaking
world:-)

Tom Petch
</tp>

Ben

---

From: Randy Bush <[email-masked]>
Date: Fri, 01 Jun 2012 17:13:23 +0900

if i have to delete through much more about this bikeshed, i will give
you some colloquial american to read.

randy

---

From: Yoav Nir <[email-masked]>
Date: Fri, 1 Jun 2012 11:16:08 +0300

> you some colloquial american to read.

"bikeshed" ?

:-)

Yoav

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 1 Jun 2012 07:41:08 -0400

On May 31, 2012:6:36 PM, at 6:36 PM, Ben Niven-Jenkins wrote:

> I don't really have any issues understanding American English but I'm regularly gobsmacked by how many North Americans struggle to understand some things that I say :-)

	I can personally attest to that. *)

	--Tom

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 01 Jun 2012 13:03:53 +0100

On 01/06/2012 00:50, Paul Hoffman wrote:
> Thank you for that most colorful analogy. :-) What I proposed is exactly
> what we are doing now, except that the changes would appear on the web
> page instead of an Internet-Draft and, five years later, an RFC. Are you
> saying that the current system (which you have not commented on until
> now) is sclerotic (a word that I have wanted to use since I learned it
> in high school)?

It depends on what you're trying to do.  For prescriptive documents which
aren't expected to change much, the I-D system works well.  But as it's
been suggested that this document falls into a category which is expected
to change from time to time, wikis offer a lot more flexibility.  Wikipedia
editing and document management policy suggests that you can end up with
quality material.  It's a bit of a departure from the I-D system, but its
lack of formality is quite appealing for documents which are not formally
prescriptive.

Nick

---

From: David Conrad <[email-masked]>
Date: Fri, 1 Jun 2012 08:12:39 -0700

On May 31, 2012, at 9:38 PM, Fred Baker wrote:
>>> The IAB decides who acts as the IETF's IANA. RFC 2860 again.
>> http://ntia.doc.gov/page/iana-functions-purchase-order
> You're correct that NTIA wants to pay someone to do the "protocol parameter" job.

Err, "pay" isn't the right word here: it's a zero dollar contract (although this doesn't preclude the contract assignee from charging to recover costs (as long as NTIA agrees)).

> The IAB can decide to not use that office.

Yep. Of course, what happens after that is left to the reader as an exercise.  Fortunately, I believe (hope?) everybody wants the same thing wrt administrative oversight of "the IANA" so that exercise won't need to be handed in to the teacher.

Regards,
-drc

---

From: Russ Housley <[email-masked]>
Date: Fri, 1 Jun 2012 17:33:37 -0400

I have a concern here.  When I did the AD review for this document, I was quite surprised how stale it had become.  For example, the document told people to send I-Ds to the Secretariat for posting instead of pointing to the online I-D submission tool.  If we put it in a wiki, there will be more people that can make update, but the publication process ensure that an end-to-end read takes place when an update published as an RFC.

So, I am left with a few questions:
- What is the similar forcing function if we use a wiki?
- Will the number of people that can make updates eliminate the need for such a forcing function?
- Who designates the editor-in-chief of the wiki?

Russ

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 02 Jun 2012 20:50:45 -0700

On 5/31/12 02:05 , Klaas Wierenga wrote:
> On 5/31/12 10:58 AM, Stephen Farrell wrote:
>>
>> I'm with Brian and Yoav on this. I don't see a need
>> to change here. And I do think we might lose something
>> if we become too PC. If a bunch of non-native speakers
>> did say "yes, I found that made the document less
>> useful" then I'd be more convinced that all these
>> changes were worth it.
> 
> As a non-native speaker I agree. I think colloquial is fine. The one
> thing causes me some trouble is all the references that Americans make
> to sports that nobody in the civilized world cares about ;-) ("left
> field", "Hail Mary passes"

If the Congregatio a Sancta Cruce hadn't come to North America from Le
Mans France and specifically to South Bend Indiana there would be no
Hail Mary.

---

From: Eric Burger <[email-masked]>
Date: Sun, 3 Jun 2012 17:40:21 -0400

What we have now *is* sclerotic. See Russ' email above yours.

Can we PLEASE eat our own dog food? Wikipedia managed not to melt down when they decided NOT TO BUILD WALLS so there were no gates for the barbarians to crush.

Let's just turn on a wiki. Wiki's have a lot of technical measures to deal with problem edits as well as social measures to ensure quality. Unlike a protocol that needs one editor, I do not think we will run into interoperability problems by having an open Wiki. Yes, you and I and others can think of exactly four individuals who will try to crash the party. There are technical measures to keep them out without burdening one or even four people with keeping up the wiki.

On May 31, 2012, at 7:50 PM, Paul Hoffman wrote:

> On May 31, 2012, at 4:30 PM, Nick Hilliard wrote:
> 
>> On 01/06/2012 00:04, Paul Hoffman wrote:
>>> Works for me, other than it should not be a "wiki". It should have one
>>> editor who takes proposed changes from the community the same way we do
>>> it now. Not all suggestions from this community, even from individuals
>>> in the leadership, are ones that should appear in such a document.
>> 
>> In practice, if this is to be a living document then it should be open for
>> inspection and poking rather than preserved in formaldehyde and put in a
>> display case, only to be opened occasionally when the curator decides the
>> glass needs some dusting.  That way leads to sclerosis.
> 
> Thank you for that most colorful analogy. :-) What I proposed is exactly what we are doing now, except that the changes would appear on the web page instead of an Internet-Draft and, five years later, an RFC. Are you saying that the current system (which you have not commented on until now) is sclerotic (a word that I have wanted to use since I learned it in high school)?
> 
>> Please put it on a wiki and put all changes through a lightweight review
>> system.  If someone makes a change which doesn't work, then it can be
>> reverted quickly and easily.  This approach is much more in line with the
>> ietf approach of informality / asking for forgiveness rather than
>> permission / rough consensus + running code / etc.
> 
> 
> In the IETF approach, only the authors of an Internet-Draft can change the contents of that draft. I hope you are not proposing a change to that as well.
> 
> --Paul Hoffman
>

---

From: John C Klensin <[email-masked]>
Date: Sun, 03 Jun 2012 18:46:44 -0400

--On Sunday, June 03, 2012 17:40 -0400 Eric Burger
<[email-masked]> wrote:

> Can we PLEASE eat our own dog food? Wikipedia managed not to
> melt down when they decided NOT TO BUILD WALLS so there were
> no gates for the barbarians to crush.
> 
> Let's just turn on a wiki. Wiki's have a lot of technical
> measures to deal with problem edits as well as social measures
> to ensure quality. Unlike a protocol that needs one editor, I
> do not think we will run into interoperability problems by
> having an open Wiki. Yes, you and I and others can think of
> exactly four individuals who will try to crash the party.
> There are technical measures to keep them out without
> burdening one or even four people with keeping up the wiki.

Eric,

FWIW, I think Paul is completely correct.  First of all, what is
sclerotic is RFC 4677.  Paul has been updating the I-D which is
much less of a problem.   Most of those "in the know" point
people to the I-D.  I think that having 4677 be the official
copy that some people consult as authoritative is a problem, but
it is another problem.

Those wiki technical measures depend on someone actively
watching for changes and having the time to step in.  I don't
think we can count on that, at least without a greater level of
effort that is required for an editor to receive comments and
integrate them.  I might change my mind if you, personally,
agreed to monitor the wiki in real time and alert the IETF list
to any possibly-questionable postings _and_ there was consensus
that those on the list wanted that additional traffic.

FWIW, I had a need on Friday to look up some details and
information that are fairly directly related to the IETF and its
relationships to some other bodies and decided to check the
Wikipedia pages that showed up in the search.  I'd give what I
found a score on accuracy and completeness of "joke" -- a few
identifiable falsehoods and a lot of convenient omissions (I
don't know or care whether those are the result of carelessness,
ignorance, or malice).  The most relevant of those pages wasn't
even flagged with "may be incomplete", "insufficient
references", or "may be biased", etc.  If you want to
demonstrate how well the Wiki system works, drop me a note
volunteering to fix the primary page involved and I'll tell you
what it is and, if you can't figure it out on your own in under
two minutes, where to get authoritative information.   In
principle, I could do it myself, but I just don't have time...
and that, and the fact that no one with the facts and time has
spotted those pages, is a large part of the problem with doing
something like the Tao by Wiki.

Also, perhaps because I have a more vivid (or paranoid)
imagination than you do, I can think of a lot more than four
individuals who would be inclined to wreck the party.  Some of
the individuals I can think of also have multiple personalities
or collections of sympathetic fellow-travelers (not just
multiple email addresses).  And, while I would hope they
wouldn't engage in such thing, if only because of the risk of
getting caught, I can think of a large and well-endowed
organization or three who might have incentives to put highly
distorted information onto an IETF Wiki that described how the
IETF worked, copy that material before it were taken down, and
then quote it in other sources.

Finally, as far as "our dogfood" is concerned, I just made a
careful search through the RFC index and a few other sources and
couldn't find an IETF Standards Track document describing the
Wiki technology and approach.  I couldn't even find an
Informational document.  So, unless I've missed something, this
particular food belongs to some other dog.  _Our_ dog food would
be to follow the precedent set with RFC 5000.  And I think that
is exactly what Paul and several others, including myself, have
been suggesting.

  best,
    john

---

From: Melinda Shore <[email-masked]>
Date: Sun, 03 Jun 2012 14:58:04 -0800

On 6/3/12 2:46 PM, John C Klensin wrote:
> individuals who would be inclined to wreck the party.

This, I think, is the show-stopper.  Back when the internet started
to become popular a well-known open access advocate put his system,
which had a passwordless root account, online, and it was basically
vandalized immediately, then vandalized again, and again, and again,
until he finally surrendered.  I really prefer to keep things as
open as possible and I would love it if the Tao were a wiki article,
but transitioning to that model would essentially mean making a
commitment for the life of the page to keeping a very close eye on
it with a quick response to vandalism.

I also think that enough of our process is actually disputed to make
a living document hard to handle.  At least with an RFC we can say
"this is what we thought it was on a given date, with considerable
review prior to publication."

Melinda

---

From: SM <[email-masked]>
Date: Sun, 03 Jun 2012 15:36:31 -0700

At 14:33 01-06-2012, Russ Housley wrote:
>it in a wiki, there will be more people that can make update, but 
>the publication process ensure that an end-to-end read takes place 
>when an update published as an RFC.

Seven individuals (approximate) submitted comments during the Last 
Call.  That's not much in terms of end-to-end read of the draft.

>- Who designates the editor-in-chief of the wiki?

HTTPbis has a good Wiki due to the efforts of two persons.  The rest 
of the IETF, excluding the IESG, do not believe that it is worth the 
effort updating a Wiki.  Instead of discussing the above questions it 
is easier to create an Wiki page and leave it to anyone with a tools 
login who cares to update it.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Sun, 03 Jun 2012 21:14:06 -0400

> it with a quick response to vandalism.

Indeed.

> "this is what we thought it was on a given date, with
> considerable review prior to publication."

Well, as long as the document is informational and an overview,
I think that can be accomplished as easily with a web page, an
editor who can be trusted to exercise a certain amount of good
sense (and whose intentions are trusted) and a process for
forcing a review if needed.   The thing that bothers me about
trying to do this by RFC is that the entire community then
wastes a huge amount of time debating the choice and style of
words and relatively minor details, after which everyone runs
out of energy to make further changes for years (other than
posting I-Ds on which there are no real controls, even an appeal
process (not that I'd expect Paul to ignore input)).   If we go
the web page and editor route, expect revisions only when real
problems are identified and otherwise do a review every year or
so, I think we can get a pretty good balance between the
slowness of the RFC-and-community-consensus process and the
difficulties of the Wiki one.

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Sun, 03 Jun 2012 21:34:33 -0400

--On Sunday, June 03, 2012 15:36 -0700 SM <[email-masked]>
wrote:

>> it in a wiki, there will be more people that can make update,
>> but  the publication process ensure that an end-to-end read
>> takes place  when an update published as an RFC.
> 
> Seven individuals (approximate) submitted comments during the
> Last Call.  That's not much in terms of end-to-end read of the
> draft.

Subramanian,

I don't think that is a fair comparison.  First of all, the Last
Call spawned the whole thread about colloquial language.  I
don't have any way to know how many of those who participated in
that thread read all the way through the document and even less
way to guess how many people were enough turned off by it to
lose interest in the Last Call, maybe after having read the
document.  Second and more important, my suggestion that we go
in the direction of a web page or wiki spawned a separate thread
that is more about the philosophy of how to handle the document
rather than about the detailed content of the document itself.
Again, I have no idea how many people other than myself looked
through the document, decided that "publish as RFC?" was the
wrong question, and as the result of that decision, concluded
that my time was better spent on medium and editorial process
than on reporting specific document comments.  So you don't know
to what extent I, or anyone else in the "making it a web page"
threads read the document through either.

My guess is that more people have volunteered to help with the
web page approach on an ongoing basis than have read the
document carefully in the last week or so.  I further guess that
"on an ongoing basis" will be better for the document than
getting a new snapshot out as an RFC and seeing how long it
takes to get stale and how long after that it takes the
community to notice.  But those are just guesses and my opinion.
YMMD.

>...
> HTTPbis has a good Wiki due to the efforts of two persons.
> The rest of the IETF, excluding the IESG, do not believe that
> it is worth the effort updating a Wiki.  Instead of discussing
> the above questions it is easier to create an Wiki page and
> leave it to anyone with a tools login who cares to update it.

See my responses to Eric and Melinda.

   john

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 3 Jun 2012 20:49:19 -0700

On Jun 3, 2012, at 6:34 PM, John C Klensin wrote:

> ... I further guess that
> community to notice. ...

I second the above statement
(my apology to John for quoting this single sentence out of his whole msg)

Lixia

---

From: SM <[email-masked]>
Date: Sun, 03 Jun 2012 22:18:54 -0700

Hi John,
>document.  Second and more important, my suggestion that we go

Fair enough.  My guess was that the Last Call was not really a Last Call. :-)

>threads read the document through either.

Yes.

>difficulties of the Wiki one.

In 1994 it was mentioned that due to the nature of the document it 
can become outdated quite quickly.  The web page approach was 
recommended.  The EDU Team ( 
http://wiki.tools.ietf.org/group/edu/wiki/EduCharter ) could be an 
alternative to take on the task.

Regards,
-sm

---

From: Dave Crocker <[email-masked]>
Date: Mon, 04 Jun 2012 08:02:55 +0200

...
>   ...  Instead of discussing the above questions it is easier
> to create an Wiki page and leave it to anyone with a tools login who
> cares to update it.

In effect, the wiki construct becomes a form of incrementally-updatable 
internet draft.  For documents involving procedures rather than 
products, this well might be a better working base than I-Ds...

But with the I-D model superimposed.

That is, perhaps what makes this workable is imposing an editor role 
onto the wiki and assign responsibility for monitoring changes to the 
editors?  (It might even be worth integrating it into the rest of the 
I-D administration environment?)

Note that this still leaves a place for published snapshots as RFCs.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: SM <[email-masked]>
Date: Mon, 04 Jun 2012 12:18:23 -0700

Hi Dave,
At 23:02 03-06-2012, Dave Crocker wrote:
>In effect, the wiki construct becomes a form of 
>incrementally-updatable internet draft.  For documents involving 
>procedures rather than products, this well might be a better working 
>base than I-Ds...

It's more of an experiment.  If it is a success someone gets all the 
glory by turning it into an I-D.  If the experiment fails the people 
who have put in the effort will have wasted their time.

I would look at this in terms of the tool used for a collaborative 
effort.  It is left to the community to decide whether further 
changes are needed for the output to reflect consensus.

>onto the wiki and assign responsibility for monitoring changes to 
>the editors?  (It might even be worth integrating it into the rest 
>of the I-D administration environment?)

There is a Trac plugin for email notifications.

I am not thinking of the integration part as it requires more than a 
lightweight effort.  Eliot pointed out that there is a socialization 
problem.  Who knows, may be the collaborative effort might help.

Regards,
-sm

---

From: Lucy Lynch <[email-masked]>
Date: Tue, 5 Jun 2012 09:39:41 -0700 (PDT)

On Mon, 4 Jun 2012, Dave Crocker wrote:

> internet draft.  For documents involving procedures rather than products, 
> this well might be a better working base than I-Ds...
>
> That is, perhaps what makes this workable is imposing an editor role onto the 
> wiki and assign responsibility for monitoring changes to the editors?  (It 
> might even be worth integrating it into the rest of the I-D administration 
> environment?)
>

I like the idea of moving towards a more lively version of the Tao and I 
agree with all those who've voiced concerns about using to open of a 
process for group editing.

I have an alternate suggestion which tries to walk the "middle way". What 
is we create the Tao as a web page with one lead editor (an a possible 
second author as needed) who is responsible for regular review and updates 
and then spin up an etherpad version of the text which can be edited by 
anyone with a tools login? The editor could then track and incorporate 
suggested changes into the canonical web page and notify the list when 
major updates occur. This would use some familiar elements of our current 
document production process and tools we already have in place and would
give the editor a way to contact those with suggested changes if further
dialogue was needed.

One question for the Tools team - can etherpad handle a long lived 
document?

- Lucy

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jun 2012 16:09:39 -0700

On May 30, 2012, at 11:22 PM, Eliot Lear wrote:

> 	• I've been told by some that the Mission of the IETF is in some way out of date.  I don't know whether this is true, but if it is, the reference should be removed.

As others pointed out, it is a BCP, it is the only BCP we have that covers the mission, so it should probably stay.

> 	• It's probably worth adding a word or two about the fact that the ISOC Board is the final appellate avenue in the standardization process.  In this way it may also make sense to move Section 3.2.1 further back behind the IAB.

I have heard that as well, but cannot find it in RFC 2026 or any of the RFCs that update 2026 (3667 3668 3932 3978 3979 5378 5657 5742 6410). It should only be in the Tao if we can point to where the rule comes from.

> 	• I don't know about anyone else, but my experience has changed with regard to there being a "fair amount of time for socializing".  I would say there is a modest amount of time for socializing.

I have met with many first-timers at IETF meetings, and they have a fair amount of time for socializing. The more meetings you go to, the less time you have to socialize. I have added "for many participants" to the sentence.

> 	• The Tao mentions that we meet once a year in each region.  I don't think that's true for Asia at this point.  The text might call out that we meet where there are participants, or words that the IAOC might provide.

It doesn't say that. It says "approximately once a year in each region". That is still true.

> 	• The last paragraph in Section 4 is outdated.  Everyone uses wireless these days– everywhere at nearly every meeting.

Good catch.

> 	• 4.12 really should be a top level section (moved further back).

This was a conscious decision made for the last Tao: put it in the middle to give the reader a sense of what the can do.

> 	• Section 5 (Working Groups) really should be moved forward (after Section 3 but before what is now Section 4).

The Tao is still normally read by people coming to their first meeting, not by someone participating for the first time on a WG mailing list.

> 	• Move acknowledgments to the back.  As it stands that text forms a disconnect between the Intro and later sections.

Done.

--Paul Hoffman

---

From: "Bradner, Scott" <[email-masked]>
Date: Fri, 8 Jun 2012 01:13:18 +0000

> I have heard that as well, but cannot find it in RFC 2026 or any of the RFCs that update 2026 (3667 3668 3932 3978 3979 5378 5657 5742 6410). It should only be in the Tao if we can point to where t…

see RFC 2026 section 6.5.3

6.5.3 Questions of Applicable Procedure

   Further recourse is available only in cases in which the procedures
   themselves (i.e., the procedures described in this document) are
   claimed to be inadequate or insufficient to the protection of the
   rights of all parties in a fair and open Internet Standards Process.
   Claims on this basis may be made to the Internet Society Board of
   Trustees.  The President of the Internet Society shall acknowledge
   such an appeal within two weeks, and shall at the time of
   acknowledgment advise the petitioner of the expected duration of the
   Trustees' review of the appeal.  The Trustees shall review the
   situation in a manner of its own choosing and report to the IETF on
   the outcome of its review.

   The Trustees' decision upon completion of their review shall be final
   with respect to all aspects of the dispute.

note that the appeal to the ISOC BopT is only if the claim is that the rules are broken 
not the application of the rules

there has never been such an appeal

Scott

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jun 2012 19:20:30 -0700

> not the application of the rules

Exactly right. What Eliot said, and others have said, is that the ISOC board is the "final appellate avenue in the standardization process". That's quite different than "the rules are broken".

> there has never been such an appeal

Happily noted.

--Paul Hoffman

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Jun 2012 10:16:01 -0400

Sigh.

These multiple threads are, IMO, a wonderful exposition of how
the IETF can waste a tremendous amount of collective time and
energy fine-tuning a document and/or procedures by a very large
committee.  If nothing else, the process often leads to victory
by exhaustion as people just give up, leaving the discussion who
have the energy (or, as a colleague would put it, "too much time
on their hands".  I plead somewhat guilty for getting sucked
back in, but I want to make a few suggestions:

(1) Can we figure out a way to converge on whether we are
editing an RFC-to-be by committee or planning something web-ish
(not distinguishing between "web page" and "wiki" for the
moment?   If the former, then there are several irrelevant
threads.  If the latter, then there are a lot of useful comments
that should be handled in a different way.

(2) At one time, one of the key differences between the IETF and
other bodies in more or less the same business was that we
allowed ourselves considerable flexibility to match how we did
things to the situation and our needs while those other bodies
had to spend huge amounts of energy getting agreement on the
exact way that something should be done before attempting to do
it.  If we are going down the "web-ish" path and haven't lost
that sense of flexibility entirely, I would like to recommend
that we perform a "let's try this, see how it works, and then
work out specific procedures for the future" experimental
engineering process rather than trying to get the details right
by committee.  In particular, I suggest that, for the initial
round of turning the current I-D into something web-ish and
establishing a model for handling suggestions and changes, we:

Ii) We appoint an Editor (or Editor-in-chief).  

(ii) Based on precedent, history, a much-better-than-decent job,
authorship of the I-D, and an orderly transition from one
publication model to the other, we should appoint Paul by
acclamation.  By that I mean that someone, ideally Russ, gets on
the list and says "is there really any objection to appointing
Paul... if not, done".  That skips, for the present, wasting
more time figuring out who makes the appointment, whose approval
is needed, whether we need a whole process (e.g., of volunteers,
lists and comments) similar to how we handle IAOC and ISOC BoT
appointments, and a whole series of other ways in which we could
waste a lot of time and then get the same result.

(iii) Let's give the Editor six or nine months of discretion and
experimental time about formats (let's at least start with a
controlled list of people who can make changes until we have a
document in place and a bit of experience -- I see no
substantive difference between a controlled-authorship Wiki and
a controlled-authorship web page other than the tools used
although we could spend lots of time debating the
non-substantive differences), editorial board composition, how
to solicit and receive input, etc.  We encourage the editor to
consult with the IESG to the extent to which the IESG (or some
IESG-chosen subcommittee) is inclined to be involved.

(iv) At the end of that period, we see if we can find an
efficient way to examine the experience, draw ideas together,
and figure out what we really want to do for the long term and
what procedures are needed to do it.  I think I just said "BOF
in Atlanta or Orlando" rather than "mail storm on the IETF
list", but, if we need to do a mail storm, let's at least have
some experience and a web-based document on which to focus,
rather than trying to have editorial, procedural,
organizational, and format suggestions all mixed up with each
other.

If we all really have this many spare cycles, perhaps many of
them would be better spent getting the document (page, wiki,...)
right rather than tuning procedures.  Perhaps some of them might
even be better invested in protocol specification.   And, on
that note, I'm going to go try to spend a little time on a
neglected WG.

    best,
    john

---

From: "Bradner, Scott" <[email-masked]>
Date: Fri, 8 Jun 2012 19:46:29 +0000

> Exactly right. What Eliot said, and others have said, is that the ISOC board is the "final appellate avenue in the standardization process". That's quite different than "the rules are broken".

just to be clear - saying "final appellate avenue in the standardization process". could be read as meaning
that a appeal of a technical decision could be made to the ISOC Board and that is not the case - 
this is why I used different language

not sure which you were supporting

Scott

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 8 Jun 2012 12:49:04 -0700

> not sure which you were supporting

I am supporting not putting anything about appeals to the ISOC Board in the Tao. They do not apply to novices.

--Paul Hoffman

---

From: Eliot Lear <[email-masked]>
Date: Fri, 08 Jun 2012 23:06:14 +0200

All,

Based on this explanation from Scott I withdraw my suggestion.  Text can
stay as it is.

Eliot

---

From: "Bradner, Scott" <[email-masked]>
Date: Fri, 8 Jun 2012 21:06:32 +0000

wfm

---

From: Glen Zorn <[email-masked]>
Date: Sat, 09 Jun 2012 08:03:14 +0700

On Thu, 2012-06-07 at 16:09 -0700, Paul Hoffman wrote:

...

> It doesn't say that. It says "approximately once a year in each region". That is still true.

A quick check of the "Upcoming IETF Meetings" calendar
(http://www.ietf.org/meeting/upcoming.html) shows that the next meeting
in Asia is scheduled for November 2015, while the last was November
2011.  How does a 4 year gap map to "approximately once a year"?

...

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Jun 2012 18:57:27 -0400

--On Friday, June 08, 2012 12:49 -0700 Paul Hoffman
<[email-masked]> wrote:

> I am supporting not putting anything about appeals to the ISOC
> Board in the Tao. They do not apply to novices.

Paul, that suggests something else which the Tao does sort of
say but maybe not clearly enough in context.  A novice really
shouldn't attempt to exercise any of our processes, especially
the more advanced/complex ones like appeals, without either a
lot of observation or seeking out advice and guidance.   It is
too easy to get tangled up in things or have an
almost-reasonable request or suggestion rejected because it is
badly presented.   Fortunately the community is ultimately
pretty friendly to newcomers/novices.  While that friendliness
may not express itself proactively, I've encountered very few
people who would not try to help get a novice pointed in the
right direction if asked for advice.  

IMO, the more clearly and broadly that can be said the better.

    john