Subject: [Pesci-discuss] Preview of PESCI draft

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Oct 2005 10:16:59 +0200

This is in the I-D queue - here are temporary URLs for a preview

http://www.geocities.com/be1carpenter/draft-davies-pesci-initial-considerations-00.html

Text file:

http://www.geocities.com/be1carpenter/draft-davies-pesci-initial-considerations-00.txt

    Brian

_______________________________________________
Pesci-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pesci-discuss

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 19 Oct 2005 14:11:12 -0500

Dear Pesci Design Team,

You guys have done a lot of work in not a lot of time. Most of it looks 
good. It wouldn't be the IETF, if no one had comments - pls. see the 
following notes.

FWIW, I'm trying to reflect my understanding of commonly-held and 
commonly-stated positions, not my own ideas about what should be happening 
(that would happen in other threads).

To cut to the chase, I have two fairly serious comments:

- In 1.2, the text says that the IETF Chair LED the design team. I don't 
believe that's actually what happened - it's not what Brian told me was 
happening - but if it was, Brian needs to recuse himself from the approval 
process. If the IETF chair REQUESTED that the design team produce this 
draft, that's fine (hint, wink).

- In 6.1, I'm concerned that I don't know who actually determines whether we 
have consensus for the action plan included in this draft. Is it the IETF 
chair? the IESG? or someone else?

Most else is editorial. My comments start with "SD:", and refer to the 
FOLLOWING text.

Spencer

p.s. I'm not going to look at Appendix A, because it was your raw inputs 
list, but I would like to see this carried forward in the document. It 
always bugged me that we threw away the raw inputs to the Problem Statement 
RFC after a couple of revisions - knowing what else was considered seems 
valuable.

1.  Introduction

SD: The following text makes "continual debate" sound a lot more positive 
than it really is. I'd suggest something like "The IETF almost continually 
debates its own process. While this is a positive indication of "openness", 
"closure" also matters, and IETF process debates are often inconclusive and 
often revisited."

   The IETF almost continually debates its own process and this is in
   many ways a healthy sign of its openness.  However, the debate is
   often inconclusive.

1.1.  Principles, Policy, Process and Procedure

SD: I have heard the phrase, "principles don't change, but procedures can 
change frequently" - I'm not sure if that's a helpful observation here or 
not, but if it is, it might give a smaller number of principles (do we 
really have 32? I thought us us as an unprincipled lot, most days).

   Before going on to discuss process change we should be clear about
   what we mean by "process", and some of the other "P" words which will
   be used in the document.

SD: This sentence was difficult to parse - if the phrase was "open 
development of documents and open resolution of organizational matters", and 
if the phrase was in quotes, I'd be able to parse it more easily.

               These
               include such things as requiring that development of
               documents and organizational matters are as far as
               possible open and "rough consensus and running code" as
               an operating principle.

1.2.  About This Document

SD: Please tell me PESCI was "simply the group of people who produced this 
document AT THE REQUEST of the IETF Chair" - if the IETF Chair LED a single 
design team, Brian should recuse himself from the approval process. Based on 
discussions with Brian, my understanding was "AT THE REQUEST", so I'm asking 
for a wording change, not a rewriting of history...

   PESCI
   has no special status in the IETF process; it is simply the group of
   people who produced this document under the leadership of the IETF
   Chair.

2.  Background reading
SD: Sadly, this probably should be "An earlier phase" (there were more than 
one).

   The early phase of the current round of process discussions led to a
   problem statement [RFC3774].

3.  Short problem analysis

SD: I would suggest "Insufficent cross-area review early in the process (an 
unsolved issue)"

   3.  Variable quality of output from WGs
       *  Unsolved issue of adequate cross-area review earlier in the
          process.

   5.  Lack of a "career path" for IESG members - "dropped in,
       overworked and chopped off"

SD: s/loose/lose/

       *  potential to loose both experience and capability of ex-ADs

SD: Expand "techspec" on first usage...

   Issues that are to be considered under the "techspec" banner are out
   of scope for PESCI.

4.1.2.  Change Management Guidelines

SD: I'm not AGAINST quantitative measures, but this comes up every time we 
discuss significant process change, just before EKR gets up and rails about 
how noisy the data is and how we change too many things at once to figure 
out what changed output can be assigned to each changed input, and we've got 
to be expecting two or three years of transition and retraining for 
significant process changes anyway. I'd drop this one for now, as much 
heartburn as it causes the engineers among us.

   G9.  Try to explicitly estimate the impact of changes before making
        them, and try to measure whether the expectations were met after
        making the change.

SD: It might be worth putting in an explicit pointer to RFC 3933 here, so 
that it's more clear that our existing BCPs would encourage this approach.

   G10. Acknowledge that some refinement of the initial proposals may be
        needed after trials.  To this end try to work expeditiously to
        provide a nearly right solution that delivers most of the gains
        rather than refining the solutions endlessly before any
        implementation (in line with the IETF's usual way of developing

4.2.1.  Development and Authorisation of the Changed Processes

SD: I got lost on "the development process" - is this actually "the process 
of developing process"? I know what I think a development process is, and 
this isn't it.

   P3. The development process must incorporate taking advice from
       *  the IESG, the IAB, the IAOC, and the Working Group chairs
       *  legal advisors

4.2.2.  The Content of the Changed Processes

SD: I would append "according to common sense, and relying on the appeals 
process to handle the breakdown of common sense in unusual cases".

   P7.  New process rules should be flexible enough to allow unusual
        cases to be handled according to common sense.

4.2.3.  Management and Leadership in the Changed Processes

SD: if we have to talk about miscarriages, could we at least call them 
"miscarriages of process"?

   The IETF prides itself on being a technically led organization (i.e.,
   our leaders are primarily technologists, rather than managers) with
   open processes which can, whenever possible, be challenged by
   participants if they feel there has been a miscarriage.

SD: I know what you're trying to say, but I think it's more like "processes 
should ALLOW that people in leadership positions remain knowledgeable", and 
even this seems snaky - I believe I remember Bradner explaining to me that 
ADs chair working groups just to make sure they don't turn into complete 
process weenies (to be fair, this was a number of years ago, and I could 
have dreamed the incident - but either way, I think we're only asking that 
the processes don't require a lobotomy, or a cessation of learning).

P13. Management and leadership of the standards process should be
        predominantly carried out by people who are technically
        competent in the area in which they are leading, and the
        processes should ensure that people in leadership positions
        remain knowledgeable about the state of the art (and beyond) in
        their areas of responsibility.

SD: "valuable" is an overstatement - "We should try to minimize the amount 
of "on the job" training required for leaders to become productive as 
quickly as possible after they are appointed."

   P14. The processes should ensure that it is possible for IETF
        participants to acquire or hone the particular skills needed for
        management and leadership positions in the IETF before taking on
        these positions, for example by forms of apprenticeship.  "On
        the job" training is valuable but we should try to give it in
        such a way that leaders are as productive as possible as soon as
        they are appointed.

SD: I would suggest "a period to contribute using their skill" - or are we 
really saying that long-term ADs can't maintain their technical skills? I 
thought not.

   P16. The processes should ensure that, so far as is possible, the
        pool of skills and experience developed by those in leadership
        and management positions remains available to the IETF and
        continues to be seen to be valued whilst giving these leaders a
        period to refresh their skill in the technical arena.

4.2.6.  Areas

SD: The majority of the IETF membership likely has little clue about "Kobe", 
except as a type of steak - it would be nice to provide any pointer as 
background for this point of first use (not everyone spends hours on IETF 
archeology, fascinating as it often is). Also - "the central focus of ... 
technical expertise in the IETF" seems slightly overblown - I'd go for "the 
central focus of ... cross-area technical expertise in the IETF", but at 
least one adjective seems indicated.

   Areas have become a fundamental structuring mechanism for IETF work
   since the Kobe reorganization.  Area Directors (ADs) are at the
   moment the central focus of management and technical expertise in the
   IETF.

SD: "ambit" is a perfectly lovely word, but I'm a 51-year-old native 
(American) English speaker and had never seen it used before. Perhaps, 
"sphere of influence" (from www.webster.com)?

   P25. Besides experts in particular areas, it is important that the
        IETF also takes an architectural view and encourages
        participants who are able to work at the overall architectural
        level both to direct the standards development work in the IESG
        ambit; and to set technical guidelines internally, monitor
        technical developments in the research and commercial world out
        side the IETF and interact with external groups.

4.2.7.  Working Groups

SD: I could be misspeaking here, but thought that we were headed toward a 
world where WG chairs are ALSO responsible for shepherding deliverables 
through the approval and publication process - perhaps including this as a 
principle is premature, but I needed to ask. Which also makes me wonder 
about using one continuous index across multiple sections for principle 
numbers - you'd like to add a P29 here, but then you have to renumber the 
rest of the way down.

   P27. WG Chairs are responsible for ensuring that WGs execute their
        charters, meet their milestones, and produce deliverables that
        are ready for publication.
   P28. WGs should be primarily responsible for the quality of their
        output, and for obtaining and responding to cross-area and other
        external review.

4.2.8.  Extended Review

SD: A number of us were SIRS volunteers, but I think the statement that "The 
SIRS experiment ... [has] shown the value of extended, cross-area review of 
documents" is grossly generous. SIRS showed that reviewers would volunteer 
(for some number of "reviewers"), that the IETF has the attention span of a 
hamster when it comes to evaluating process change, and that WGs had no 
appetite for additional review steps that didn't bypass review steps later 
on. IMO. I would also note that I've gotten pushback on technical objections 
based on how late in the approval cycle Gen-ART reviews happened - "haven't 
these guys suffered enough?", and "jeez, they deployed this stuff four years 
ago anyway, and it sort of works". Which leads me to suggest a P33 - 
"Technical show-stoppers are always relevant, at any point in the approval 
process".

   The SIRS experiment and the General Area review team have shown the
   value of extended, cross-area review of documents.  Currently most
   such review is carried out too late in the document life cycle for
   best effectiveness.

5.1.  Components Not Considered for Major Change in this Document

SD: "This process" - the PESCI process? or something else?

   ISOC      ISOC acts as IETF's legal parent and guarantor.  This
             process is not at liberty to change the relationship
             between ISOC and IETF.

SD: I cannot get from the following IAB writeup to the conclusion that there 
is no reason to change the IAB. The second paragraph seems justification 
enough to include IAB changes as in-scope, without reference to anything 
else..

   IAB       The main function of the IAB is architectural oversight of
             developments in the Internet.  This includes monitoring
             standards development work to ensure that it does not
             adversely impact the existing Internet, setting guidelines
             for architectural aspects of development, helping to
             determine what new working groups should be chartered,
             keeping a watching brief on technical developments outside
             the IETF, and providing statements on such developments as
             appropriate.

             The IAB currently acts as the second line of appeal for
             decisions of the IESG on standards development and other
             matters.  This function is not an ideal fit with the
             general architectural remit of the IAB: the competencies of
             the IAB members do not necessarily equip them to deal with
             the process appeals that come to them from the IESG.  Some
             of the members of the IAB may consider them a distraction
             from their architectural role.

5.2.  Components Considered for Major Change in the Document

SD: I would append "for final cross-area review, only for ensuring that 
final cross-area review has been performed".

   IESG      The IESG is central to the processes of standards
             development in the IETF.  The steering role of the IESG in
             acceptance of new work, formation, and chartering of WGs,
             monitoring of WGs, and final stages of document processing
             seems to be appropriate, as it is essential to coordinate
             these functions.  This does not imply that the IESG must be
             solely responsible for final cross-area review.

SD: It may be worth noting that IESG decisions can be appealed, but that 
this is not a fast or cheap process.

             Another area where process changes might lead to greater
             confidence in the standards development process is the
             degree of self-regulation which the IESG exercises: in many
             process related disputes the IESG is expected to act as
             judge and jury on actions in which it is itself involved.

  Working Groups

SD: It may be worth appending, "appears to be difficult to achieve, 
especially since so many working groups disband when their specifications 
are published as proposed standards:.

             The main areas for concern here are ensuring high quality
             output and maintaining momentum over the period of
             development, particularly in the later stages when the
             creative work is essentially finished and the work is
             mainly polishing.  Active management by supervisors
             together with more rigorous and earlier review of documents
             seems to be required.  Taking work through from initial
             standardisation to full standard appears to be difficult to
             achieve,

   NOMCOM    The NOMCOM provides the means of selecting leaders and the
             volunteer managers for the IETF.  The process by which this
             is performed is time consuming and could be considered
             onerous for participants, but it is vital that the process
             remains as open as possible and endeavours to keep the IETF
             as free of undue external influences as possible.

SD: If you're scoping out NOMCOM process change parameters, please include a 
note about the desire to get better community input on non-incumbent 
candidates - discussed on IETF Discussion List, I believe?

             Changes to these processes should ensure that overlaps of
             role (as regards those performing the selection and the
             leaders being selected) do not arise and that the workload
             of the NOMCOM does not get out of hand.

6.1.  Change Process Proposal

SD: It bothers me that this document handwaves approval of process change 
("the IESG (and ISOC Board of Trustees) will respect that consensus and 
approve it") - who actually DECLARES the consensus that the IESG and ISOC 
BoT then respect? Note that I haven't got a better answer, but the default 
now looks like "Brian declares consensus (or lack thereof) based on [fill in 
the blank here], and if no one successfully appeals to IAB/ISOC BoT, we know 
where we're going" - and if this isn't the default, what is?

   The teams should function with an open discussion list, in the same
   way that the PESCI committee has done.  The result of the committee
   should be tested against the IETF consensus in the normal fashion; we
   believe that if there is clear IETF consensus that the proposal makes
   sense, the IESG (and the ISOC Board of Trustees) will respect that
   consensus and approve of it.

---

From: Scott W Brim <[email-masked]>
Date: Wed, 19 Oct 2005 18:47:49 -0400

> Dear Pesci Design Team,

Dear Spencer ... half the pesci group is in bed already.  I'll give my
personal opinions.  If I don't say something, it's because the issue
is substantive or belongs to someone else, and I'm waiting for them.

> 1.  Introduction
> 
> SD: The following text makes "continual debate" sound a lot more
> positive than it really is. I'd suggest something like "The IETF almost
> continually debates its own process. While this is a positive indication
> of "openness", "closure" also matters, and IETF process debates are
> often inconclusive and often revisited."
> 

The "often revisited" bit feels useful, but I think "closure matters"
is already implied.

> SD: I have heard the phrase, "principles don't change, but procedures
> can change frequently" - I'm not sure if that's a helpful observation
> here or not, but if it is, it might give a smaller number of principles
> (do we really have 32? I thought us us as an unprincipled lot, most days).
> 

That's one of the distinctions we were trying to imply.  I agree that
we have too many principles listed.  We were in a bit of a hurry and
only did a couple passes sorting them out.  On the other hand imho
most IETFers are very principled :-).

> 2.  Background reading
> SD: Sadly, this probably should be "An earlier phase" (there were more
> than one).
> 

ok

> SD: I would suggest "Insufficent cross-area review early in the process
> (an unsolved issue)"
> 

ok

>   Issues that are to be considered under the "techspec" banner are out

ok

> SD: I'm not AGAINST quantitative measures, but this comes up every time
> we discuss significant process change, just before EKR gets up and rails
> about how noisy the data is and how we change too many things at once to
> figure out what changed output can be assigned to each changed input,
> and we've got to be expecting two or three years of transition and
> retraining for significant process changes anyway. I'd drop this one for
> now, as much heartburn as it causes the engineers among us.
> 

I didn't think quantitative measures were intended.  "Explicitly
estimate".  I often try to wean people away from "physics envy" in
administration and back to allowing human judgment.  Since you thought
they were, there's work to do, so we should put in "not necessarily
quantitative".

> 
> SD: It might be worth putting in an explicit pointer to RFC 3933 here,
> so that it's more clear that our existing BCPs would encourage this
> approach.
> 

dunno ... others?

> SD: I got lost on "the development process" - is this actually "the
> process of developing process"? I know what I think a development
> process is, and this isn't it.
> 

Yes, it's supposed to be more of P2 ("the process for developing and
agreeing these changed processes"), focusing on the "developing" bit.
 I think.

> SD: I would append "according to common sense, and relying on the
> appeals process to handle the breakdown of common sense in unusual cases".
> 

no objection

>   participants if they feel there has been a miscarriage.

ok :-)

> 
> SD: I know what you're trying to say, but I think it's more like
> "processes should ALLOW that people in leadership positions remain
> knowledgeable", and even this seems snaky - I believe I remember Bradner
> explaining to me that ADs chair working groups just to make sure they
> don't turn into complete process weenies (to be fair, this was a number
> of years ago, and I could have dreamed the incident - but either way, I
> think we're only asking that the processes don't require a lobotomy, or
> a cessation of learning).
> 

ok

> 
> SD: "valuable" is an overstatement - "We should try to minimize the
> amount of "on the job" training required for leaders to become
> productive as quickly as possible after they are appointed."
> 

ok

> 
> SD: I would suggest "a period to contribute using their skill" - or are
> we really saying that long-term ADs can't maintain their technical
> skills? I thought not.
> 

Well, that's my experience.  You have your choice, you can go for
breadth or depth, and your reach in both directions decreases after
40.  It's certainly true that we want to allow a period for them to
*increase* their skill.  Maybe they won't degrade (much), in which
case it's not just about refreshing it.  Others?

> 
> 4.2.6.  Areas
> 
> SD: The majority of the IETF membership likely has little clue about
> "Kobe", except as a type of steak - it would be nice to provide any
> pointer as background for this point of first use (not everyone spends
> hours on IETF archeology, fascinating as it often is). Also - "the
> central focus of ... technical expertise in the IETF" seems slightly
> overblown - I'd go for "the central focus of ... cross-area technical
> expertise in the IETF", but at least one adjective seems indicated.
> 

(1) nnngg, let's not try to describe the Kobe thing in a nutshell.  Do
we have something we can reference?

(2) I do believe ADs are the central focus of technical expertise.
Maybe they don't have it in the specialties, but it all comes together
at the ADs at this time.

>        side the IETF and interact with external groups.

Elwyn?

> 
> 4.2.7.  Working Groups
> 
> SD: I could be misspeaking here, but thought that we were headed toward
> a world where WG chairs are ALSO responsible for shepherding
> deliverables through the approval and publication process - perhaps
> including this as a principle is premature, but I needed to ask. Which
> also makes me wonder about using one continuous index across multiple
> sections for principle numbers - you'd like to add a P29 here, but then
> you have to renumber the rest of the way down.
> 

We were trying hard not to be *too* premature.

> 
> 4.2.8.  Extended Review
> 
> SD: A number of us were SIRS volunteers, but I think the statement that
> "The SIRS experiment ... [has] shown the value of extended, cross-area
> review of documents" is grossly generous. SIRS showed that reviewers
> would volunteer (for some number of "reviewers"), that the IETF has the
> attention span of a hamster when it comes to evaluating process change,
> and that WGs had no appetite for additional review steps that didn't
> bypass review steps later on. IMO. I would also note that I've gotten
> pushback on technical objections based on how late in the approval cycle
> Gen-ART reviews happened - "haven't these guys suffered enough?", and
> "jeez, they deployed this stuff four years ago anyway, and it sort of
> works". Which leads me to suggest a P33 - "Technical show-stoppers are
> always relevant, at any point in the approval process".
> 

ok ... but what would you say?

PESCI

> 
> SD: I cannot get from the following IAB writeup to the conclusion that
> there is no reason to change the IAB. The second paragraph seems
> justification enough to include IAB changes as in-scope, without
> reference to anything else..
> 

There's plenty of reason to change the IAB, but not this round.

>             solely responsible for final cross-area review.

but they are not, at this time.

>             judge and jury on actions in which it is itself involved.

ok ... I thought we did that somewhere.

> especially since so many working groups disband when their
> specifications are published as proposed standards:.
> 

ok

> SD: If you're scoping out NOMCOM process change parameters, please
> include a note about the desire to get better community input on
> non-incumbent candidates - discussed on IETF Discussion List, I believe?
> 

I dunno, that's just one of many factors.  I would be careful about
calling it out especially since things that are tend to become
shibboleths.

> SD: It bothers me that this document handwaves approval of process
> change ("the IESG (and ISOC Board of Trustees) will respect that
> consensus and approve it") - who actually DECLARES the consensus that
> the IESG and ISOC BoT then respect? Note that I haven't got a better
> answer, but the default now looks like "Brian declares consensus (or
> lack thereof) based on [fill in the blank here], and if no one
> successfully appeals to IAB/ISOC BoT, we know where we're going" - and
> if this isn't the default, what is?
> 

I'm stepping back from this one because I'm out of time.  I look
forward to others' opinions.

Thanks ... Scott

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 19 Oct 2005 18:21:31 -0500

Dear Awake Half of Pesci Design Team ("you know who you are"),

Thanks, Scott, for quick feedback. There were only a couple of "huh?" 

> we have something we can reference?

Dave Crocker gave some references in 
http://www.alvestrand.no/pipermail/problem-statement/2003-March/001098.html 
a couple of years ago (how long have we been talking about process change?). 
It looks like http://ietf.org/rfc/rfc1640.txt?number=1640 would be the RFC 
reference, with ftp://ftp.ietf.org/ietf-mail-archive/ietf/1992-07 as the 
source material. Dunno if this helps.

> ok ... but what would you say?

Sorry, this one was too easy. "The General Area review team has shown ..." 
Does MIB-doctor review count, for MIBs that aren't done in OPS?

> There's plenty of reason to change the IAB, but not this round.

That's fine - could we at least delete the justification for including it 
this round from the draft? :-) I got whiplash reading it.

> but they are not, at this time.

This is probably premature-creep. Good catch.

> calling it out especially since things that are tend to become

That's fair.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2005 09:10:43 +0200

> we have something we can reference?

RFC 1396, Steve Crocker's report on the POISED WG.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2005 10:07:24 +0200

> forward to others' opinions.

PESCI stepped back from this one too.......

I think the answer's likely to be "the team discusses its result openly in 
the IETF, using process X, and some person designated by the IETF chair 
declares that he has concluded that the IETF has consensus".

This follows a model of the IETF as "WG", and the team analogous to the 
"design team". Still unclear whether the person declaring IETF consensus 
has to be part of the team developing the proposal or not (practice for 
design teams varies).

That declaration of consensus would then be evaluated by the bodies having 
to approve the document (including the IESG and the ISOC BoT), and my hope 
is that it's going to be "pretty obvious" - because the spectacle of trying 
for process change based on a declaration of consensus that can be 
questioned to death in detail may cause us all to prefer the 51% 
dictatorship of voting :-(

Of course, one danger is that the only changes we're able to make is the 
obvious ones..... but that seems a danger in all efforts to change the IETF.

                       Harald

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 20 Oct 2005 09:46:24 -0500

... and I'm aware that we're talking about Brian like he was in a cave 
somewhere, but ignoring that for a moment ...

> PESCI stepped back from this one too.......

I understand this temptation ("Note that I haven't got a better answer 
..."), but it's a pretty important question.

> declares that he has concluded that the IETF has consensus".

If this is the right answer, it would be good to designate "some person" 
pretty quickly. The alternative is that the choice of "some person", and 
community acceptance of /acquiescence in the team result, get discussed at 
the same time - if you don't like the team result and think "some person" 
likes the team result, you're likely to push back on both.

> has to be part of the team developing the proposal or not (practice for 

This probably isn't worse than other ways we've applied the protocol 
development process to do non-protocol stuff, I guess.

> is that it's going to be "pretty obvious" - because the spectacle of 
> trying for process change based on a declaration of consensus that can be 

I agree completely.

> obvious ones..... but that seems a danger in all efforts to change the 

Ack.

Spencer

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2005 17:20:26 +0200

--On torsdag, oktober 20, 2005 09:46:24 -0500 Spencer Dawkins 
<[email-masked]> wrote:

>> I think the answer's likely to be "the team discusses its result openly
>> in  the IETF, using process X, and some person designated by the IETF
>> chair  declares that he has concluded that the IETF has consensus".
>
> community acceptance of /acquiescence in the team result, get discussed
> at the same time - if you don't like the team result and think "some
> person" likes the team result, you're likely to push back on both.

I think it would have to be decided at effort start time, as part of the 
"charter" for the design-team-like thing (DTLT?); the logical candidates 
are the leader of the DTLT and "some person or group outside the DTLT".

Corresponding case in WG: WG chair as part of design team, leading it, or 
outside of it.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Oct 2005 16:34:19 -0700

Scott, et al,

> ...

I suggest that the truth and implications of this view be 
(re-)considered very carefully. 

It seems to be a fundamental and commonly-held view, but I suspect that 
a great deal of the IETF's problems come from our citing it too 
casually.  ADs are certainly chosen for presumed and/or demonstrated 
technical expertise, but that is a very different statement than Scott 
made.  And I suspect Scott's statement reflects the typical community view.

Here is the dilemma:

1. ADs essentially never initiate a working group activity; other folks 
in the community do.  So the perception of community need comes from the 
community and the effort to pursue that need comes from the community.

2. Technical drafts that are input to new working groups do not come 
from the cognizant Area Director.  Technical drafts that are produced by 
a WG do not come from the cognizant AD.

3. The cognizant AD is not supposed to do any of the principal work -- 
and on the average they do essentially none of the actual work -- in 
creating a specification, because then they would have a conflict of 
interest in any evaluation of the work.

So, the people we are saying "are the central focus of technical 
expertise" for the IETF do not typically initiate the technical work or 
do the technical work, when they are the cognizant AD. 

So what does it mean to say that they are the central focus?

d/

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Oct 2005 11:54:21 +0200

Spencer Dawkins wrote:
...
> happening - but if it was, Brian needs to recuse himself from the 
> approval process. If the IETF chair REQUESTED that the design team 
> produce this draft, that's fine (hint, wink).

On the point of fact, I chaired the telechats we held and I produced
the early draft, which Elwyn then took over. As for "led", this
is the IETF - ever tried leading even a small herd of cats?

But there is something more interesting here. Clearly if it comes
to a typical ballot in the IESG, I would most likely feel I had to
recuse myself.

> 
> - In 6.1, I'm concerned that I don't know who actually determines 
> whether we have consensus for the action plan included in this draft. Is 
> it the IETF chair? the IESG? or someone else?

Well, first we'd need to get to the point where the active participants
in the discussion had largely converged, which most likely means the
people on this list. (Some people may disagree unless this becomes
a formal WG, but I think that's not the main question.) Then we'd need
to put the question to the IETF. Who calls consensus for the IETF as
a whole (i.e. not "the IESG decides X" but "the IETF decides X")?
At normal course and speed, that would be the IETF Chair's job, I'd say.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Oct 2005 11:59:20 +0200

> So what does it mean to say that they are the central focus?

Two comments.

1. For many years, the IESG's guidance to NomCom has asked for
a balance between technical and managerial expertise in future ADs.

2. I believe a more accurate statement is the the ADs are the central
arbitrators of technical expertise. They get to appoint WG chairs,
expert reviewers, and the like. That's at least as important as their
own technical skills, imho.

    Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 21 Oct 2005 09:12:51 -0500

I'm quite a bit more comfortable with "central arbitrators of technical 
expertise", and think the statement is probably even true - others?

Spencer

---

From: Scott W Brim <[email-masked]>
Date: Fri, 21 Oct 2005 10:48:56 -0400

> expertise", and think the statement is probably even true - others?

Can you find a phrase that sounds a little more natural and less like
George Will?

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 21 Oct 2005 10:31:19 -0500

I'm sure I've seen a quote about Jon Postel as RFC Editor being the arbitor 
of technical matters for the Internet - ah, here it is, at 
http://en.wikiquote.org/wiki/Jon_Postel

He worked quietly for years as keeper of the RFCs and final arbiter in 
technical matters when consensus couldn't be reached. Postel believed that 
decisions he had made in the course of his work over the years had been for 
the good of the community and that starting a company to profit from those 
activities would have amounted to a violation of public trust. ~ Where 
Wizards Stay Up Late (1996) by Katie Hafner and Matthew Lyon

I guess I could argue that that's what we ask the ADs to do, today.

- from www.webster.com

1 : a person with power to decide a dispute
2 : a person or agency having the power of deciding

with only one thesaurus entry, for "mediator" - some of the related words 
were quite amusing, in the IETF context...

Entry Word: mediator
Function: noun
Text: one who works with opposing sides in order to bring about an agreement 
<if you two cannot resolve this argument on your own, we'll have to bring in 
a mediator>
Synonyms arbiter, arbitrator, conciliator, go-between, intercessor, 
intermediary, interposer, middleman, peacemaker
Related Words moderator; bargainer, negotiator; appeaser, pacifier, 
reconciler; broker; agent, attorney, deputy, factor, procurator, proxy; 
liaison; ambassador, emissary, envoy, messenger; delegate, representative; 
busybody, interferer, meddler; judge, referee, umpire; adviser (or advisor), 
counselor

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 Oct 2005 11:32:18 +0200

> Can you find a phrase that sounds a little more natural and less like

I don't know who George Will is but I agree the phrase is a bit
clumsy - if we agree on the notion, we can surely find a better word.

    Brian

---

From: Elwyn Davies <[email-masked]>
Date: Sun, 23 Oct 2005 13:26:08 +0100

Brian E Carpenter wrote:

>>> I'm quite a bit more comfortable with "central arbitrators of 
>>> technical expertise", and think the statement is probably even true 
>>> - others?
>>
>>
>>
> I don't know who George Will is 

Neither did I, but I happened to come across a reference to him 
yesterday. For the benefit of the uninformed in the rest of the world he 
is apparently a venerable (since 1977!), conservative opinion columnist 
for the Washington Post and television talking head. I presume he has 
some of the same predilictions for flowery language to which I am prone. 
Maybe also the same urge to ensure that some of the more precise words 
in the half million or so that English provides us with do not fall into 
abeyance.

> but I agree the phrase is a bit

The word you are probably after is 'arbiter', rather than 'arbitrator'.

 From the OED:

    arbiter

• *noun* *1* a person who settles a dispute. *2* a person who has 
influence over something.

— ORIGIN Latin, ‘judge, supreme ruler’.

Both senses and the origin seems quite appropriate ;-)

Regards,
Elwyn

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 23 Oct 2005 16:34:15 +0200

Interesting en-latn-uk-x-ietf debate.
I would love the AD to be considered as the users interests steward.
jfc

At 14:26 23/10/2005, Elwyn Davies wrote:
>>>>technical expertise", and think the statement is probably even true - others?
>>>
>>>
>>>
>yesterday. For the benefit of the uninformed in the rest of the 
>world he is apparently a venerable (since 1977!), conservative 
>opinion columnist for the Washington Post and television talking 
>head. I presume he has some of the same predilictions for flowery 
>language to which I am prone. Maybe also the same urge to ensure 
>that some of the more precise words in the half million or so that 
>English provides us with do not fall into abeyance.
>
>— ORIGIN Latin, 'judge, supreme ruler'.
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 23 Oct 2005 10:08:06 -0700

"Arbiter" works for me. It seems to work in US-English and UK-English... if 
we could think of a better word, that would work, too.

The problem I have with George Wills is not his vocabulary :-)

Spencer

At 14:26 23/10/2005, Elwyn Davies wrote:
>Neither did I, but I happened to come across a reference to him yesterday. 
>For the benefit of the uninformed in the rest of the world he is apparently 
>a venerable (since 1977!), conservative opinion columnist for the 
>Washington Post and television talking head. I presume he has some of the 
>same predilictions for flowery language to which I am prone. Maybe also the 
>same urge to ensure that some of the more precise words in the half million 
>or so that English provides us with do not fall into abeyance.
>
>. *noun* *1* a person who settles a dispute. *2* a person who has influence 
>over something.
>
>- ORIGIN Latin, 'judge, supreme ruler'.
>

---

From: Melinda Shore <[email-masked]>
Date: Sun, 23 Oct 2005 16:40:29 -0400

> in the half million or so that English provides us with do not fall into

That would not be the particular problem with George Will's
writing.

> The word you are probably after is 'arbiter', rather than 'arbitrator'.

To be honest, I don't like either word here.  I think what's
under discussion is basically just personnel management.  "Arbiter"
suggests that the IESG members are making judgements about who's
a smarty-pants and who's a meathead.  While I'm sure that's true,
I hope that doesn't become part of their official job description
and that instead the job description focuses on the management
aspects of identifying working group leadership, getting rid of
working group leadership, and so on.

Melinda

---

From: Elwyn Davies <[email-masked]>
Date: Sun, 23 Oct 2005 22:04:27 +0100

>That would not be the particular problem with George Will's
Ah!  What we sould call a Sun reader's vocabulary in the UK then!

>working group leadership, and so on.
Remember that we are discussing a view of what the AD's are today!  This 
doesn't mean it is what we should be aiming for

Personally,
- I feel 'arbiter' is a good reflection of the current state of play, 
whether that is what it should be or not, and
-  I would suggest that we should leave off wordsmithing the commentary 
and concentrate on the principles.

Regards,
Elwyn.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 23 Oct 2005 14:05:18 -0700

Hi, Melinda,

> working group leadership, and so on.

I happen to like a lot of ideas that JohnK had in 
draft-klensin-stds-review-panel-00, which divides what the IESG does now 
into two leadership groups (one for specification approval and one for 
process management), but I think what Melinda is hoping for is a change from 
current practice.

Spencer

---

From: Dave Crocker <[email-masked]>
Date: Sun, 23 Oct 2005 14:30:01 -0700

> Remember that we are discussing a view of what the AD's are today!  
> This doesn't mean it is what we should be aiming for

right.

> whether that is what it should be or not, and
me too.

d/