Subject: [edu-team] updated version of the charter

From: Avri Doria <[email-masked]>
Date: Wed, 15 Mar 2006 07:43:24 -0500

Hi,

I have done an edit pass on the charter, and while trying to minimize  
the re-write tried to take the discussion into account.

Please take a look and send comments etc.  Brian saw an intermediate  
pass and after the team has had a chance to do a quick review,  
intends to send it on to the IESG and IAOC for their comments.  I  
apologize for only giving you all a short time, but since he wants to  
send it in  on Friday morning (US time) I ask you to get your  
comments in today and tomorrow.

thanks
a.
_______________________________________________
edu-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/edu-team

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 15 Mar 2006 08:04:51 -0600

Dear Avri (and rest of the EDUcators),

Mostly fine. A couple of suggestions follow.

I have never been involved in topic selection for the ongoing WG chair 
training, but have attended most sessions since it started, and think that 
the topics have been terrifically relevant and helpful. I'd suggest listing 
a few of them (possibly IPR considerations, current DISCUSS criteria, and 
something else), and I'd probably break this out into its own bullet.

Also, I noticed that

- Technical oriented topics intended to help participants do their
   jobs in the IETF better.  The classes in this category can be very
   varied and change over frequently. Topics are chosen where there is
   reason to believe that relevant technical knowledge is in fact
   lacking in part of the IETF community.  Class that have been
   offered include:
    - DNS for Applications Programmer
    - Introduction to Security and writing a Security section
    - Overview of IETF routing principles and technology.

Seems to have a typo somewhere around "change over frequently" (delete 
"over"?), and if you're editing this exact text anyway, I'd change "very 
varied" to "varied", because phrases like this sound really funny when 
someone reads it aloud, and we don't want to make anyone giggle if someone 
reads the charter to the IESG.

Beyond this, I think we could demonstrate "running code" that people who 
need to understand Security and DNS in order to work in other areas don't, 
so we're justified in offering classes on these topics, but I'm thinking 
that telling the IETF that there are people at the IETF that don't 
understand routing *and need to understand routing, in order to work in 
other areas* will be a lot harder sell. I would not list this as one of the 
"offered include" tutorials, if that's the reason we're giving for offering 
technical training (just because I don't think the reason justifies offering 
this tutorial).

I saw JohnK's note (forwarded by Brian), and 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.

Just to be clear - I own copies of both editions of Interconnections, and am 
thrilled that the IETF offers a tutorial that provides a high-level summary 
of this material. I'm not trying to put up a barrier, I'm trying to "route 
around" a potential barrier that might actually be erected for good reason.

And, having typed this, I'm now thinking that it would be good for us to 
request proposals for technical tutorials on

- "Taking IPv6 into account in your IETF specification work" (this is 
actually on the Int-Area agenda for IETF 65, presented by some chick named 
Margaret Wasserman, with the following outline:
   - Common errors that people have made
   - How to properly take IPv6 into account,
and I think it's likely that there are people who need to think about IPv6 
outside the INT area :-)

- the current state of end-to-end and NAT traversal (I wish Cullen wasn't on 
the IESG, sometimes, but other people who are active in this area include 
Jonathan Rosenberg, Dan Wing, and Francois Audet).

- Internationalization (Harald Alvestrand or, in a splendid burst of irony - 
John Klensin!)

Not as part of the current round of charter discussions, but - has anyone 
besides me looked at the way IEEE does "tutorials"? People are actually 
expected to present "incoming" work at the tutorial level, in evening 
sessions. For example, the IEEE 802.3 tutorials are available at 
http://www.ieee802.org/3/tutorial/index.html. I don't know if this is 
someplace we ought to go, but at least it does seem that other SDOs are OK 
with presenting technical tutorials, at certain points in the process. (If 
you reply to this part of my note, please put it in another thread, so we 
don't drive Avri and Brian nuts as they prepare for discussions with IESG)

Thanks,

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Mar 2006 17:29:51 +0100

> Beyond this, I think we could demonstrate "running code" that people who need to understand Security and DNS in order to work in other areas don't, so we're justified in offering classes on these topics, but I'm thinking that telling the IETF that there are people at the IETF that don't understand routing *and need to understand routing, in order to work in other areas* will be a lot harder sell. I would not list this as one of the "offered include" tutorials, if that's the reason we're giving for offering technical training (just because I don't think the reason justifies offering this tutorial). 

Those are my words and I'm sure we need to say something.
This is a point where there is most sensitivity in the
IAOC and IESG. If you can find phrasing that doesn't
imply we have ignorant people in the IETF, that would
be good.

    Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 15 Mar 2006 10:54:42 -0600

I'm not good at language for the sensitive, but maybe something like

- Technical training on specialized topics that non-specialists also need to 
understand, in order to do their work in the IETF. The classes in this 
category are topicalcapable instructors), and vary from IETF to IETF. 
Classes that have been offered in the past include:

Thanks,

Spencer

From: "Brian E Carpenter" <[email-masked]>

>> need to understand Security and DNS in order to work in other areas 
>> don't, so we're justified in offering classes on these topics, but I'm 
>> thinking that telling the IETF that there are people at the IETF that 
>> don't understand routing *and need to understand routing, in order to 
>> work in other areas* will be a lot harder sell. I would not list this as 
>> one of the "offered include" tutorials, if that's the reason we're giving 
>> for offering technical training (just because I don't think the reason 
>> justifies offering this tutorial).
>

---

From: Avri Doria <[email-masked]>
Date: Wed, 15 Mar 2006 11:59:17 -0500

On 15 mar 2006, at 11.29, Brian E Carpenter wrote:

> If you can find phrasing that doesn't

well the idea is not that it is ignorance but specialization.
anyone who think they can be an expert in all things IETF is either  
deluded or totally awesome.

how about something like:

  Technical oriented topics intended to help participants do their
    jobs in the IETF better.  The classes in this category are
    varied and change over frequently. 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.
    Class that have been offered include:

---

From: Susan Harris <[email-masked]>
Date: Wed, 15 Mar 2006 12:06:11 -0500 (EST)

>  jobs in the IETF better.  The classes in this category are
                     ^^^^^^
                  more effectively.

>  reason to believe that relevant technical knowledge that is important

---

From: Radia Perlman <[email-masked]>
Date: Wed, 15 Mar 2006 10:30:14 -0800

I might add a phrase about "facilitating cross-area participation and 
awareness". And I'm not sure
the sentence that starts "Topics are chosen...." adds too much, so I 
might delete it.

So perhaps:
 Technical oriented topics are intended to help participants do their
   jobs in the IETF better, and facilitate cross-area participation and 
awareness
by giving an overview of the technology in specific techncial areas.  
The classes in this category are
   varied and change over frequently.

And possibly delete the next sentence:

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Mar 2006 16:38:57 +0100

Somewhere in that space or Avri's language.

In answer to Radia I am concerned that if there is no hint
as to why technical topics are chosen, we will be told the
charter is too open.

Avri, please choose how to phrase it in this draft - I need
to get this to IAOC tomorrow for sure (I'm being asked for it
on a conf call as we speak).

    Brian

Spencer Dawkins wrote:
> - Technical training on specialized topics that non-specialists also 
> need to understand, in order to do their work in the IETF. The classes 
> in this category are topicalcapable instructors), and vary from IETF to 
> IETF. Classes that have been offered in the past include:
> 
> Thanks,
> 
> Spencer
> 
>>> Beyond this, I think we could demonstrate "running code" that people 
>>> who need to understand Security and DNS in order to work in other 
>>> areas don't, so we're justified in offering classes on these topics, 
>>> but I'm thinking that telling the IETF that there are people at the 
>>> IETF that don't understand routing *and need to understand routing, 
>>> in order to work in other areas* will be a lot harder sell. I would 
>>> not list this as one of the "offered include" tutorials, if that's 
>>> the reason we're giving for offering technical training (just because 
>>> I don't think the reason justifies offering this tutorial).
>>
>>