Subject: Re: [edu-team] Charter v6

From: Avri Doria <[email-masked]>
Date: Wed, 3 May 2006 18:33:33 -0400

Hi,

The conversation about the charter has pretty much died down.

I think in general there is a rough consensus for the charter.

There were however, a few issues brought up, that caused me to  
recommend a few wording changes that are marked below.  I would like  
to hear from any member of the team if they object to the wording  
changes made and would like to hear if the changes change anyone's  
view for or against the charter.

Some of the issues:

- titles of the tutorials did not reflect the reality of the topic  
presented.
--  I think this was essentially true and suggest replacements  
similar to those suggested.

- problem with distinction between tutorials of general interest and  
tutorials that are of interest to protocol designers.
-- to me this seems a hard distinction to make.  i consider myself a  
protocol designer, yet a lot of things are generally interesting to  
me.  and often i find something useful for one of the protocols i am  
working on in the oddest places - the virtues of cross  
fertilization.  so i looked at the text and could not really figure  
out to change it without opening all sorts of cans of worms.

- discussion of why we do technical tutorials
-- i think trying to change the charter on this point at this point,  
would open even more cans of worms.

-Problems with the language about example.
-- changed the language almost as recommended.
  (must admit an evil voice in my head made me want to include the  
UN's favorite phrase for making a list intentionally fuzzy: inter alia)

- A reference to doing logisitcs in cooperation with iasa had, i  
believe, been agreed to before, but was essentially left out.  i  
wasn't sure if IAD was more appropriate the iasa, but i went for  
breadth.

Unless I hear in the next few days that someone is strongly against  
the charter as modified below, I recommend that it be taken by the  
general Area AD as something we have rough consensus on.

thanks for the comments,

a.

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

replace:
>     Classes that have been offered include:
with:
As an example, some classes that have been offered include:

replace:
>     - DNS for Applications Programmers
with:
What protocol designers need to know about DNS

>     - Introduction to Security and Writing a Security section
Replace:
>     - Overview of IETF routing principles and technology.
with:
Bridging, switching, and routing: A comparison

>
> The Team's responsibility also includes scheduling and logistical
> planning for these sessions,

add in cooperation with the IASA

> 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: "Margaret Wasserman" <[email-masked]>
Date: Thu, 4 May 2006 07:04:53 -0400

Hi Avri,

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

I think that you have the "in cooperation with IASA" part backwards.  I
think that we need to cooperate with IASA on the logisitics and scheduling,
not on the staffing and contents.

Margaret

---

From: Thomas Narten <[email-masked]>
Date: Thu, 04 May 2006 08:59:08 -0400

Comments on the charter (some are on older parts...)

> > | by the IESG on [DATE TBD].

Personally, I don't like this "appointed annually" wording. The
coordinator (and why don't we call the position a chair? I do think it
is better to use familiar roles (e.g., WG chair) rather than defining
new terms that have unclear definitions - just what is the role of the
coordinator and how does it differ from a traditional chair?).

Previously, I think there was agreement that the chair/coordinator
serves at pleasure of the AD. What more is needed to be said? I don't
think it is desirable to imply that its only once per year that one
considers whether a new chair is needed, or that once a chair is
appointed they have the position for a year (no matter what).

I think annual review is a fine thing, but that can/should just be
done, not written into the charter.

> > |   the IETF standards process.

Sorry, but I really don't understand what the new sentence does/means.

> As an example, some classes that have been offered include:

Note: using the words "that have been offered" leads to the problem of
"we've done it in the past, so its reasonable to presume that
continuing to do them the future is fine". But, the issue we keep
circling around is whether tutorials like routing are appropriate and
should be in scope.

> What protocol designers need to know about DNS

better: s/protocol designers/application protocol designers/

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

We've talked some about having the IETF review what we do prior to
doing a tutorial. While I don't think we should have to go to wider
review for everything, it might make sense to recognize that on
general tutorials, they appear to be more controversial, and we should
thus consult a bit more broadly. I'd support some text saying we would
consult with the wider community before introducing a new general
tutorial.

> >     people to quickly catch up to what the WG is doing

Not sure what this last one is. I imagine some things here that would
be good to do. E.g., encuraging the development of protocol overviews
(that can go directly into protocol documents). But there are other
"tutorials" that I am less sure about. Is this specifically directed
at providing guidance to WGs, so that WGs do this, as opposed to EDU
being responsible? If so, I'm fine with this, but it might be good to
make that clear (and again, I'm suggesting this to avoid some
potential charter criticism that I can imagine being raised).

Also, note, some people may react to the notion of WGs doing
"tutorials", since it might suggest WGs should be doing overview
presentations, something that is controversial.

Or maybe just drop this? (We can still discuss and decide to do
something, I don't think that not listing something automatically
means we can't do it.)

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 May 2006 13:22:38 +0200

...
> coordinator and how does it differ from a traditional chair?).

I wouldn't mind it being called "chair" although for a "team",
it might be more conventional to use a word like "leader".

> done, not written into the charter.

I tend to disagree because I think explicitly stating that there will
be annual review is a useful message to the community in itself. But I
am absolutely not singling out EDU for this - I would be quite happy for
it to be stated as a general rule in fact (i.e. the minimum requirement
is that all charters and all appointments should be reviewed annually).

> Sorry, but I really don't understand what the new sentence does/means.

It means that while I don't agree with John Klensin's worst fears about
possible anti-trust implications of biased tutorials, I think we need
a lever to tell the teachers that they are *not* allowed to give
opinions or recommendations about IETF choices. Maybe it should
be written more explicitly?

     Brian

---

From: Avri Doria <[email-masked]>
Date: Sun, 7 May 2006 11:19:51 -0400

On 4 maj 2006, at 05.59, Thomas Narten wrote:

> I do think it

this was change i suggested in one of the earlier versions.  so i  
guess i will explain.

i agree with the comment made later that the edu team is different  
from a wg, so to have a 'wg chair' would presume all sorts of roles  
that the edu person doesn't really have.  so  i see it as overloading  
the role with content from the more precisely defined term 'chair'.

on the other hand, why change it to coordinator instead of leaving it  
as is?  for me at least, the word 'leader' is also overloaded - all  
kinds of 'i am the decider' connotations and historical references to  
The Leader.  and i don't think it necessarily reflects what a edu  
team person does.  as the i see the role, it is more one of enabling  
the efforts of many professional volunteers into a concerted action -  
educating.

but if people can't live with the 'coordinator', i can live with  
going back to leader.  i do think it would be an error to change it  
to chair - it is a different role and should have a different name.

thanks

a.