Subject: [edu-team] Charter v6

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Apr 2006 16:45:12 +0200

I've reviewed the comments made by IESG members and recent discussions,
and come up with my own version 6 of the charter. I have put change
bars at the left (except for typos and trivia).

It's clear we need to resolve the issues raised in Margaret's message
before putting this out for community review.

The IESG comments, fyi, were relatively few.

Apart from nits, Jari Arkko said:

 >> - creation and management of realistic milestones, use of regular
 >>   project checkpoints
 >> - how to provide tutorial documentation and presentations to allow
 >>   people to quickly catch up to what the WG is doing
 >>
 >>
 >
 > These items seem very general to me. Is this really something that
 > we should provide?

To which I answered:

 > For those of us who have been to typical management training classes
 > on communication skills, project managemet etc, this may seem generic.
 > But for relatively junior geeks who have never been exposed to such classes,
 > I do think it is a gap that it is useful to fill.

And Lesie Daigle suggested clarifying the reporting line, which I did,
especially in relation to

 > I believe that needs to be tied more closely with IETF management
 > structures, otherwise it is the EDU team leader who decides what
 > is efficient, effective and necessary for the IETF.

and she said

 > And I still have no clue what "DNS for Application Programmers"
 > has to do with any of that.

which is the technical tutorials issue again.

    Brian

OVERVIEW:

The Education (EDU) Team manages the internal education efforts of the
IETF with the goal of enabling IETF operational improvement.  The
elements of this effort include improving the efficiency of IETF WG
efforts and increasing the effectiveness of IETF leaders and
participants by highlighting and clarifying their roles and
responsibilities and by instruction on the means by which they can be
effective in those roles.

STRUCTURE:

This education effort is managed by the EDU Team, which consists of a
team coordinator and several members. The team coordinator is
| appointed annually by, and reports to, the General Area Director, and 
the members of the team are chosen by the team coordinator, with the
| approval of the General Area Director. This charter was approved
| by the IESG on [DATE TBD].

In order to allow for community visibility and input into IETF
educational activities, the archives of the EDU Team mailing list are
publicly available, and a public discussion list is available for open
discussion of education efforts.  The Edu Team maintains a web site
that contains the minutes of all EDU Team meetings as well as other
information about ongoing work. The team also holds periodic open EDU
Team meetings (approximately once per year at IETF meetings) to report
on plans and  progress and to receive community input and feedback.
| It is also expected that the team will solicit and accept input
| on topics to be covered from the IESG, IAB, IAOC and the body
| of WG Chairs.

CURRENT Activities (As of March 2006):

The EDU Team is responsible for providing the educational tutorials
held on the Sunday before IETF meetings.  Several types of tutorials
are offered on a periodic basis.

- Newcomer's training is a traditional offering that proceeds the
   creation of the EDU team by many years.  This tutorial attempts to
   give new, and continuing, participants an introduction to the
   processes and practices of the IETF and its meetings.  In recent
   years the Newcomers training has also been given in the local
   language when the IETF meeting is held in a non English speaking
   country.
 
- The EDU team offers several other classes for both participants and
   leaders in IETF processes.  These include:

       - WG Leadership training, which gives a introduction to the
    	  roles and dynamics in the working groups. 
    
       - Ongoing seminars for current WG chairs that covers topics of 
          particular concern to those actively involved in leading the WGs.
          Some of the recent topics covered include:
          - MIB construction
          - IESG DISCUSS criteria
          - IPR considerations
          - Managing a WG meeting

       - RFC Editors training: the class covers the basics required to
    	  produce a well formed RFC.  Recently this class has been
    	  taught by a member of the RFC Editor team.

- Technical oriented topics intended to help participants do their
   jobs in the IETF more effectively.  The classes in this category
   are varied and change frequently over time.  Topics are chosen
   where there is reason to believe that relevant technical knowledge
   that is important to the IETF community as a whole can be
   effectively shared by specialists in the topic within a short
|   (e.g. two hour) session.
|   Material presented in such classes will be purely tutorial
|   in nature and will be explicitly outside the scope of
|   the IETF standards process.

    Classes that have been offered include:
    - DNS for Applications Programmers
    - Introduction to Security and Writing a Security section
    - Overview of IETF routing principles and technology.

The Team's responsibility also includes scheduling and logistical
planning for these sessions, deciding what will be presented by whom
at topical sessions, managing the development and review of training
materials, and maintaining an archive of our training materials on the
EDU Team web site.

FUTURE PLANS (March 2006 - September 2007):

Over the next 18 months, we will enhance and extend our current
training activities for participants, document editors and WG chairs,
based on community feedback and the judgment of the education team.

o Augment WG leadership offerings and ongoing WG chairs training to
|  cover topics helpful in running a successful WG given the IETF's
|  varied international range of participants.  Topics to be
  considered include:
  - IPR management in a WG
  - creation and management of realistic milestones, use of regular
|    project checkpoints, within the WG process
  - how to build rough consensus in a WG
  - how to provide tutorial documentation and presentations to allow
    people to quickly catch up to what the WG is doing
  - how to manage mailing lists with summaries of complex threads,
    documenting all sides of arguments, together with decisions and
    rationales

o A focus of the EDU team will be on looking for new ways to present
  IETF educational material.  Currently all slides set from the
  classes are available on the web, but there is not any web based
  instructional material available.

o The team will investigate new training initiatives intended to
assist the IETF in improving its effectiveness and efficiency. Some of
the ideas to be discussed include the following, though not all idea
will turn into classes:

  - Bringing new work into the IETF. This would be a process topic
    aimed at all IETF participants. The material would include
    information on how to bring new work into the IETF, including how
    to bring documents into existing WGs and how to organize a BoF and
    attempt to form new WGs. Although this information is intended to
    encourage participants to bring interesting work to the IETF, the
    class would also cover IPR and other implications of a decision to
    pursue work within the IETF.

  - IETF Protocol Engineering Fundamentals These topics would explore
     technical considerations that all IETF document authors and
     reviewers should consider when developing protocols within the
     IETF.

  - How to structure protocol documents, to make them easier to read,
      understand, and implement.

  - How to make the best use of the new tools being offered by the
     tools group and others.  Some examples might be issue trackers or
     xml2rfc.

Information regarding these topics will be published on the EDU Team
web site, and while these topics may not all become classes,
information on the investigation into these topics will be reported on
the community.

CONTACT INFORMATION:

Team Coordinator: Avri Doria (avri at acm.org)

General Area Director: Brian Carpenter (brc at zurich.ibm.com)

Mailing Lists:

Education Team: [email-masked] 
Archive: https://www.ietf.org/mailman/listinfo/edu-team

General Discussion: [email-masked] 
Subscribe/Archive: https://www.ietf.org/mailman/listinfo/edu-discuss

Education Team Web Site: http://edu.ietf.org/
_______________________________________________
edu-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/edu-team

---

From: Avri Doria <[email-masked]>
Date: Tue, 11 Apr 2006 11:09:56 -0400

On 11 apr 2006, at 10.45, Brian E Carpenter wrote:

> CURRENT Activities (As of March 2006):

at this point should this be as of April

> FUTURE PLANS (March 2006 - September 2007):

and perhaps (May 2006 - November 2007)

> materials, and maintaining an archive of our training materials on the

Maybe I forgot to include it, but wasn't this supposed to include  
that this is done in cooperation with IASA/IAD?

> | appointed annually by, and reports to, the General Area Director,

if you are going to do an annual review and reassignment/replacement,  
you probably should indicate when this happens.  i would suggest that  
it follow the introduction of new ADs, i.e. 1st IETf of the year, so  
that a new General Area director could pick someone new without  
prejudice shortly after taking over.

Also, is there an expectation that one only serve one year?  I have  
no issue with that if that is what is intended, otherwise you may  
want to use (re)appointed or some such indicator.

a.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Apr 2006 17:29:21 +0200

below...

> and perhaps (May 2006 - November 2007)

Sure

> Maybe I forgot to include it, but wasn't this supposed to include  that 
> this is done in cooperation with IASA/IAD?

Yes, IASA is more generic than IAOC in fact.
> prejudice shortly after taking over.

Sorry, I meant to mention that innocent little change in my cover note :-)

I believe in general it's good to have a renewal cycle for all
appointments. So I would envisage inserting this in any team charter
that comes up for review.

Synchronizing with the First IETF makes sense as a general
rule (but of course people may need to step down due to job changes
etc at any time).
> 
> Also, is there an expectation that one only serve one year?  I have  no 
> issue with that if that is what is intended, otherwise you may  want to 
> use (re)appointed or some such indicator.

I'm no believer in term limits in a volunteer community. I think an annual
cycle does give both parties a little trigger to consciously review
whether things are working well or badly.

     Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 11 Apr 2006 11:01:30 -0500

I've pretty much decided that I'm outside the team concensus on this topic, 
but, since Brian asked for input, I'll try to summarize what I've been 
thinking (and maybe not saying clearly).

> |   the IETF standards process.

I don't understand what this means (just from the last sentence in the 
proposed charter). I'm pretty sure (based on reading a long e-mail chain) 
that it's trying to say something like, "we will not present technical 
topics that are actively being standardized in the IETF in tutorials", but 
that's not what I'm getting from the new text.

>    - DNS for Applications Programmers

Perhaps I am Yet Again Confused. The title of this tutorial in Paris was 
DNS@IETF 63. I'm not even sure what that means, but this tutorial was 
explictly NOT "DNS for Applications Programmers". From 
http://www3.ietf.org/proceedings/05aug/slides/protut-0/sld2.htm:

"Goal:
Give the audience basic understanding of DNS to be able to facilitate new 
uses of DNS
Tutorial Focus: Big picture
Not software help
DNS != BIND
No gory protocol details"

which is NOT "DNS for applications programmers", and I thought this tutorial 
did exactly what we had hoped - give people who are saying "and we can store 
these 64KB attributes in the DNS" or "and since DNS has a reverse tree, we 
can just look up all the hostnames based on IP addresses" reasons to think 
two times (repeat as needed). The guidance starting at about 
http://www3.ietf.org/proceedings/05aug/slides/protut-0/sld14.htm seems about 
right for what I thought technical tutorials should be doing.

I am guessing that some of the confusion on "technical tutorials" may result 
from people reading the title in the charter, not bothering to look up what 
the tutorial is actually about, and just firing away. Not good.

>    - Introduction to Security and Writing a Security section

I've been watching this tutorial for a while (at least six or seven times). 
I think it's been spending more time on "Introduction to Security" and less 
time on "Writing a Security (Considerations) Section" in recent offerings, 
but that's just the kind of feedback presenters need ("not a problem, just 
something to think about when planning for IETF 66"). This tutorial topic is 
exactly what I think technical tutorial topics should be. Every RFC is 
required to have a Security Considerations section, which can't say "there 
are no security considerations", and can't say "just use IPsec". Whether or 
not we adjust five percent of the content, we are doing the right thing by 
offering this tutorial.

>    - Overview of IETF routing principles and technology.

Perhaps I haven't said this strongly enough. I cannot imagine why this 
tutorial would qualify, under the criteria to "help participants do their 
jobs in the IETF more effectively".

- One hopes that participants in RTG and OPS are beyond this stage of 
expertise, especially since "IETF routing" includes "works at Internet 
scale".

- It is possible that SEC and RTG guys should talk more often, but I'm not 
sure this is the right venue.

- If anyone in INT, TSV, APP, and probably RAI needs to understand routing 
principles and technology, something is broken.

I'd drop this tutorial from the charter, not because I want to hide it, but 
because I don't think it qualifies under the heading it's listed under. In 
http://www1.ietf.org/mail-archive/web/edu-team/current/msg01317.html, I said 
words like

"I ... suggest that we explicitly say that technical topics may also be 
offered as a service to the community, with disclaimers that the contents of 
these (and perhaps other) presentations represent one point of view, but 
that the EDU team believes the presentation is "helpful enough" to justify 
sharing with the community. Or something. Mumble."

So I am totally OK with adding a heading that does work, and keeping this 
tutorial under it - just not with the current text, which is threatening our 
ability to offer any tutorials beyond process topics because it's tying two 
types of technical tutorials together, and they really need to be discussed 
separately.

I am also totally OK with NOT giving tutorials that don't qualify under the 
existing heading (based on Thomas/Margaret's "what's important?/what's in it 
for the IETF?" notes).

Thanks,

Spencer

---

From: "Margaret Wasserman" <[email-masked]>
Date: Tue, 11 Apr 2006 12:44:31 -0400

Hi Spencer, 

> I've pretty much decided that I'm outside the team concensus 
> on this topic, but, since Brian asked for input, I'll try to 
> summarize what I've been thinking (and maybe not saying clearly).

Well, if that's true then I'm out there with you, so at least we aren't
alone out here.  :-)

I agree with everything you said in this note and would like to comment on a
couple of portions:

> Perhaps I am Yet Again Confused. The title of this tutorial 
> in Paris was DNS@IETF 63. I'm not even sure what that means, 
> but this tutorial was explictly NOT "DNS for Applications 
> Programmers". 

I did not attend this class, but I _thought_ that it was supposed to teach
Internet protocol designers about how IETF protocols should (and shouldn't)
make use of the DNS.  What information should/shouldn't be placed in the
DNS?  How do you know if you need your own RR type or if using a TXT record
is the right thing to do?  If you do need an RR type, how do you get one?
If those are the topics covered, than this may be an appropriate tutorial
with an inappropriate name.  It doesn't have anything to do with application
programmers, although it would be of use to application protocol designers,
among others. 

> I think it's been spending more time on "Introduction to 
> Security" and less time on "Writing a Security 
> (Considerations) Section" in recent offerings, but that's 
> just the kind of feedback presenters need ("not a problem, 
> just something to think about when planning for IETF 66"). 

Right.  I think that the Security Tutorial has been slowly trending in the
direction of becoming a general technical tutorial rather than focusing on
IETF-specific information, and that we should try to turn that trend around.
Not a major problem at this point, just something to think about for the
future.

> Perhaps I haven't said this strongly enough. I cannot imagine 
> why this tutorial would qualify, under the criteria to "help 
> participants do their jobs in the IETF more effectively".

I share this concern.  I have similar concerns about an MPLS tutorial for
the same reasons.  Personally, I love to hear Radia speak about anything,
and I would enjoy attending this tutorial.  I might also enjoy an MPLS
tutorial, because I'm naturally curious and would like to know more about
MPLS.  If I really wanted to learn these things, though, there are books and
other tutorials out there.  It is not clear to me how holding either of
these tutorials will benefit the IETF and/or help IETF participants to
participate more effectively, etc.

> So I am totally OK with adding a heading that does work, and 
> keeping this tutorial under it - just not with the current 
> text, which is threatening our ability to offer any tutorials 
> beyond process topics because it's tying two types of 
> technical tutorials together, and they really need to be 
> discussed separately.
> 
> I am also totally OK with NOT giving tutorials that don't 
> qualify under the existing heading (based on 
> Thomas/Margaret's "what's important?/what's in it for the 
> IETF?" notes).

Based on my earlier comments, it is probably obvious that I prefer the
second choice.

However, I am also okay with the idea of including the concept of general
technical tutorials in our proposed charter having an open discussion about
whether we should hold them.  I just don't want us to pursue the first
choice under the cover of pursuing the second one...

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Apr 2006 11:24:18 +0200

Spencer Dawkins wrote:
> I've pretty much decided that I'm outside the team concensus on this 
> topic, but, since Brian asked for input, I'll try to summarize what I've 
> been thinking (and maybe not saying clearly).
> 
> proposed charter). I'm pretty sure (based on reading a long e-mail 
> chain) that it's trying to say something like, "we will not present 
> technical topics that are actively being standardized in the IETF in 
> tutorials", but that's not what I'm getting from the new text.

I didn't want to go that far. I wanted to draw a line in the sand
(definitely sand, not concrete) and maybe suggest later that every
tutorial starts with an EDU "Note Well"...

Information presented in this tutorial is not intended as
a contribution to the IETF standards process and does not
represent the position of any IETF WG, Area Director, the IESG,
the IAB, the IETF Trust, or the Internet Society. It is provided
for educational purposes only.

[Obviously, we'd get counsel to review such a text in
the light of JCK's arguments.]

      Brian

---

From: Avri Doria <[email-masked]>
Date: Wed, 12 Apr 2006 07:18:53 -0400

hi,

> tutorial starts with an EDU "Note Well"...

i think this is a good suggestion in today's litigious world whether we
remove the contentious 'technical' classes or not.

> for educational purposes only.

i am not sure how this works if it is an area director giving a class.

> the light of JCK's arguments.]

good idea.  probably wise to have the entire issue reviewed by counsel.

---

From: Radia Perlman <[email-masked]>
Date: Thu, 13 Apr 2006 11:58:03 -0700

>>participants do their jobs in the IETF more effectively".
I've been travelling, so don't quite have time to catch up with the 
whole thread at this point. However,
let me explain why knowing a little about other areas helps one "do 
one's IETF job more effectively".
Things like VRRP and IPv6 are very affected by how bridging works, even 
though bridging is
not standardized within IETF. Similarly, it is essential to have some 
knowledge of general
security issues, management issues, NATs, internationalized naming, just 
for a few examples,
in areas in which participants don't necessarily realize the affect. You 
can't just teach someone
"this is how to write a security considerations section" without 
explaining "this is how to think
about security, how to begin to understand some of the issues in 
security". It is hard to predict
which areas might be relevant to one's own protocol, or conceptual ideas 
that might pop up
in another area that might give insight, and it also helps if an area 
wants, for instance,
a security person to come in to help, if there is a quick reasonably 
painless way for
the security person to get introduced to the area rather than having to
read 800 pages of incomprehensible acronyms. People don't want to spend 
a lot of time, and employers
don't want to spend any money, on this cross-fertilization stuff, so it 
is immensely useful,
and vital for the health of the technical output of the IETF, for IETF 
to facilitate this sort of thing.

Radia

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Apr 2006 13:09:57 +0200

Hi,

At this point I want to put the draft charter out for
IETF-wide comment. We don't have clear consensus in the team
on this point, so let's see what the community thinks.

     Brian

Radia Perlman wrote:
>>> Perhaps I haven't said this strongly enough. I cannot imagine why 
>>> this tutorial would qualify, under the criteria to "help participants 
>>> do their jobs in the IETF more effectively".
>>>   
>

---

From: Thomas Narten <[email-masked]>
Date: Tue, 18 Apr 2006 11:11:08 -0400

> on this point, so let's see what the community thinks.

Hmm. This sounds like punting the problem (on tutorials). Kind of like
when a WG says "there is no consensus, lets just send it to the IESG
and they can decide". All we'll likely do is replay the same
conversation we've already had.

I really think that this group needs to decide what it wants to do
here. It is not immediately clear to me what the consensus is or that
we lack it. Has there been a formal consensus call where we can get
everyone (including the lurkers) to express an opinion?

Also, I think a strong case can be made that if there is no consensus
for item X, than exclude X from the charter. I.e., just like with WG
items, it should not be enough that there is _some_ support for
X. There needs to be sufficient support. I.e., at least rough
consensus to bring it in.

Note: I count 13 members at http://edu.ietf.org/members. I am honestly
wondering whether there are 3 in favor of current charter, 3
opposed. But that leaves 7 other voices...

Thomas

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 18 Apr 2006 17:36:35 +0200

Hi all,

I'm trying to follow this thread reading the email archive, but I'm not
actually sure everything has been archived, as looking at
http://www1.ietf.org/mail-archive/web/edu-team/current/index.html, can find
only since April 9/2006 ?

So if someone can forward me the draft charter under discussion, probably
can at least try to voice some input (out of 14, not 13 ;-)).

Regards,
Jordi

> De: Thomas Narten <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Tue, 18 Apr 2006 11:11:08 -0400
> Para: Brian E Carpenter <[email-masked]>
> CC: 'EDU Team' <[email-masked]>
> Asunto: Re: [edu-team] Charter v6
> 

**********************************************
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.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 18 Apr 2006 10:43:54 -0500

Hmmm. We're headed into "I have a hammer, so these are all nails" territory, 
but as long as we stay out of the TALL grass and can all see each other's 
heads, maybe we can talk a little...

From: "Thomas Narten" <[email-masked]>

> conversation we've already had.

This is not a bad analogy. The differences probably include (1) 
theoretically a WG can claim some expertise in the problem being punted, 
while I'm not sure we do, and (2) if John's concerns are grounded on this 
planet, I'm way out of MY depth on one particular topic.

In general (and Harald and Margaret can do the riff on this better than I 
can), we had some pretty serious early discussions about how "teams" are 
like WGs, and how they are different. We're not a WG now and we're making up 
how things work as we go along. This isn't bad, but it does mean we'll be 
rewarded for being deliberate and intentional, since we're still doing lots 
of things for the first time, and setting precedents all over the place.

Our use of two mailing lists (one public, one private) is the most recent 
example of a precedent we set a long time ago, without really discussing 
much, that someone is questioning now. Avri's understanding about who 
serves, and for how long, is another - and if I understood Brian's musings 
recently, he's leaning for finite commitment periods (with renewals as 
appropriate) for a lot of Gen-Area stuff, which is very different from WG 
chairs.

> everyone (including the lurkers) to express an opinion?

I don't remember a "hey, lurkers, this means you" call on this topic.

> consensus to bring it in.

I'm somewhere close to agreeing, but confused enough to want to ask a couple 
of questions.

- This is obviously the right thing to do with WG items, because WGs have to 
get consensus on their output, and WGs plan to (at least convince ADs that 
they can ever) finish. Are either of these conditions true for EDU-team? (My 
understanding of Thomas's position is not that technical training is evil, 
but that it competes with other stuff that should have priority)

- The other reason this mindset works for WGs is that people who don't agree 
with excluding X from WG Y's charter are free to submit a BOF request for X, 
and this isn't even viewed as an end run, because everyone knows that WGs 
punt on possible charter items just to keep focused on current charter 
items. Is the team OK with Bride-of-EDU that takes the technical tutorial 
discussion (to use one example) somewhere else?

> opposed. But that leaves 7 other voices...

FWIW, I'm not sure *I* know whether I'm "in favor" or not.

Thanks,

Spencer

---

From: Avri Doria <[email-masked]>
Date: Tue, 18 Apr 2006 11:46:20 -0400

> only since April 9/2006 ?

did you try next page at the top.  seems to work for me.

> can at least try to voice some input (out of 14, not 13 ;-)).

ooops, added you to the mailing list, but not the list on Edu.  will  
take care of that.

apologies.

a.

---

From: Avri Doria <[email-masked]>
Date: Tue, 18 Apr 2006 11:53:16 -0400

Hi,

Speaking of the charter, i am not sure that we have 3 against the  
charter because that is not a question that has been asked.  At the  
moment we are discussing a single point on the charter and i don't  
necessarily assume that people are against the charter because they  
have issues on the point of technical tutorials.  i also don't assume  
they are in favor of the charter.

In terms of Edu team process, we have never done a Team last call on  
a document then again we have never done an RFC.  And while we have  
normally worked on a consensus basis, we have not adopted a strict WG  
model.  I guess that is also a question for the team:  should the  
team be run like a WG?

If we are run like a WG, however - if i understand correctly,  
charters are discussed but they are not consensus documents as they  
are owned by the responsible AD and the IESG.

I have been treating this charter as i have treated other charters  
when i used to be a WG (co)chair; discuss it but leave it to the AD  
to make the final decisions about disposition.  Brian has, i expect,  
heard all of the discussions and i thought it was his prerogative to  
do with the charter as he please within IESG constraints.  Are there  
WG that do WGLC on charters?

I am certainly willing to do so, if the team thinks this is the way  
we want to work.  Or if the General AD thinks we should.

a.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 18 Apr 2006 17:58:39 +0200

Yes, sorry, missed that ... Also Thomas sent me the link to the specific
email and I actually looked at it before but didn't realized the charter was
embedded at the end.

Reading it right now ...

Regards,
Jordi

> De: Avri Doria <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Tue, 18 Apr 2006 11:46:20 -0400
> Para: JORDI PALET MARTINEZ <[email-masked]>
> CC: <[email-masked]>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 18 Apr 2006 18:26:23 +0200

Ok. ... Trying to make a kind of summary, reading some of the recent emails.

I basically agree with Spencer comments below.

I see a main difference between EDU and a regular WG. I don't think we
should be forced to go for a review of every document (tutorial) and have a
showstopper situation. I'm ok with asking the community to review our
documents and have suggestions to improve them, but if we wait for that to
decide if a given training-set is ready or not, could become a bit dangerous
and never be out.

I'm sure that we will try our best to be as much technically accurate as
possible, but being a training it can never be perfect, just a facilitator
to get the people introduced in each specific topic, and including the
note-well indicated in one of the emails (which I agree we should do) we are
safe. We should always point to the participants to all the relevant
documents for accurate-final info.

Even if we get the "best" slides that we could (going for a long review
process), it may happen that the presenter make an emphasis in the wrong
way, etc., so never will be perfect.

Even more ... In some of the cases, our contents aren't technical, so may be
subjective, exists several ways to do something (which may be perfectly
valid), etc.

So yes, the presenter has the ability to influence participants view, but
the contrary seems to me impossible, even if the slide-set is perfect,
unless the classes are pre-produced, taped, and edited (and then probably we
come into a loop of review and start again almost forever).

I do lots of trainings and I try to be as much objective as possible, and if
I want to say something with is not technically proven or where I know there
are alternative views, I always insist on that point to the attendees, so
they make sure to review other documents, and form their own opinion/choice.

The best way we can try to avoid "as much as possible that" is choosing the
participants on the team in a very distributed way (as I guess is being
done), and making sure to be open for public review, but not necessarily to
be enforced to that. Our own criteria will be enough to foresee a real
problematic situation with any document, right ?

There is any other specific open questions that I can try focus on my review
(considering that just joined) ? I looked at the chapter and in general have
no discrepancies with what I see.

Regards,
Jordi

> De: Spencer Dawkins <[email-masked]>
> Fecha: Tue, 18 Apr 2006 10:43:54 -0500
> Para: 'EDU Team' <[email-masked]>

---

From: Thomas Narten <[email-masked]>
Date: Tue, 18 Apr 2006 13:18:16 -0400

> charter because that is not a question that has been asked.

Fair enough. My point was mostly to say we seem to be split, with a
bunch of silent lurkers on the main (only?) issue of controversy with
proposed charter. I don't want to just punt resolving this to the
IETF.

> model.  I guess that is also a question for the team:  should the  

IMO, mostly. Unless there is a good reason to use another approach.
What is frustrating me is that I feel like we're spending a
disproportionate amount of time on this topic, yet we don't seem to be
resolving it.

> are owned by the responsible AD and the IESG.

I think this is a valid point. But I'd differ just slightly, in that
the charter is a "contract" between the group (and perhaps more to the
point the group's chair) and the AD/IESG. Both need to agree, or
trouble lies ahead.

> WG that do WGLC on charters?

Oh yes. Many/most WGs do the equivlent of LCs on charters, i.e., prior
to formally presenting them to their AD. But that doesn't mean a
charter is a pure WG consensus position either.

> we want to work.  Or if the General AD thinks we should.

I think we (within EDU) should figure out what we want our charter to
be. Or if we can't, we need to frame the question we want the
community to help us answer.

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Apr 2006 17:15:49 +0200

> proposed charter. I don't want to just punt resolving this to the

OK, so may I ask Avri to establish whether we have consensus on
the charter apart from the technical tutorial issue, and to
see if we can reach consensus on that issue?

    Brian