Subject: [mpowr] Rough Strawman of MPOWR Charter

From: Margaret Wasserman <[email-masked]>
Date: Fri, 23 Jan 2004 12:45:16 -0500

Hi All,

We have written a strawman MPOWR charter (see below).  This
charter is still quite rough and includes several open
questions that are included in the text of the charter.

There is also still an open question regarding whether there
is community support to form a WG in this area at all, but we
thought that a strawman charter might help us to focus our
mailing list discussions.  We are also planning to request a
BOF on this topic in Seoul.

Your feedback on the attached charter would be appreciated.

Thomas Narten and Margaret Wasserman

Management Positions -- Oversight, Work and Results (mpowr)

[Version 03]

Chair(s):
TBD

General Area Director:
Harald Alvestrand <[email-masked]>

General Area Advisor:
Harald Alvestrand <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: https://www1.ietf.org/mailman/listinfo/mpowr
Archive: http://www1.ietf.org/mail-archive/working-groups/mpowr

Description of Working Group:

The MPOWR WG has two broad goals: (1) to clarify the roles and
responsibilities of WG chairs, document editors and other WG
participants, and (2) to shift more work and responsibility from the
IESG to WG chairs, in those cases where doing so is likely to improve
the overall work flow while still ensuring appropriate accountability
to the IETF as a whole. As an example, it may be appropriate for WGs
to more formally demonstrate that their documents have been adequately
reviewed prior to having them be advanced.

The MPOWR WG may choose to publish BCPs that update RFC 2418 and/or
section 6 of RFC 2026, as needed to enact these clarifications or
changes.

The work of this group will follow a three stage process:

     (1) Reach a common understanding of the current roles and
         responsibilities of various parties (IESG, WG Chairs,
         Document Authors/Editors, WG participants) within IETF
         WGs, including how and if our current roles and
         responsibilities differ from those documented in RFCs
         2418 and 2026.

     (2) Determine if changes are needed to our roles and
         responsibilities.  If so, determine what changes are
         required, whether or not the changes require updates
         to RFCs 2418 or 2026, what the benefits of those
         changes are expected to be, and what impacts those
         changes may have on accountability, workload and
         participant motivation.

     (3) If the community believes that it is necessary
         and advisable, publish BCPs that update RFC 2418
         and/or RFC 2026 (section 6) to clarify or modify
         our roles and responsibilities. [Question: Should
         the WG be chartered for this task up-front, or
         should the WG be re-chartered if it decides that
         this step is necessary?]

This group will take an incremental approach to change, considering
each proposed change separately and deciding whether or not to enact
it.  The group may later merge any changes that require BCP updates
into a single pair of RFC 2418bis and RFC 2026bis documents.

The WG is expected to produce the following work items (as needed):

     (1) An (Informational or BCP?) RFC describing the current
         roles and responsibilities of IESG members, WG chairs,
         Document Editors/Authors and WGs. This document should
         offer a high-level description of these roles, similar
         to the current descriptions in RFC 2418 (sections 1.2
         and 6) and RFC 2026 (section 6).

     (2) A set of Internet Drafts proposing specific
         changes to IETF roles and responsibilities that
         will increase the effectiveness of the organization
         and move some responsibilities from the IESG
         to a wider group of IETF participants (such as
         WG Chairs, authors/editors or other WG participants).

         Each I-D should include an analysis of the proposed
         change describing what impact the change is expected
         to have on accountability, workload and participant
         motivation.  Each I-D should also make it clear whether
         the change would require updates to the BCPs or could
         be achieved through procedural or cultural/attitude
         changes without requiring changes to the current BCPs.
         The WG may decide, on a case-by-case basis, to publish
         some of these I-Ds as Informational RFCs.

     (3) If the WG believes it is necessary, a set of BCP RFCs
         updating RFC 2418 and section 6 of RFC 2026 may be
         produced to update, clarify and/or modify the
         organizational and process roles of various parties
         within the IETF.

     (4) If the WG believes it is necessary, an updated version
         of work item (1) may be produced, documenting the
         desired roles of various parties within the IETF.

[Question: Should we omit items 3 and 4 from this charter and
indicate that the group should re-charter if these are
considered necessary?  Or include them now?]

It would be a perfectly acceptable outcome for this WG to determine,
after completing the first and second work items, that no updates to
RFC 2418, RFC 2026 or work item (1) are required.

[Question:  Should we add wording to limit the scope of the
changes that this WG is chartered to consider?  For instance,
should we explicitly state that this WG is not expected to
make changes to the document track or the document approval
process?]

[Question:  Should we including any wording about how this
WG relates to the ICAR and NEWTRK efforts?]

Goals and Milestones:

[JAN 04      Community discussion of WG scope and goals]
[FEB/MAR 04  WG chartered, if appropriate]

MAY 04       Current Roles and Resp published as WG I-D
JUL 04       First round of Change Proposals published as
                  individual I-Ds for WG consideration
AUG 04       First WG Last Call on Current Roles and Resp
SEP 04       First round of Change Proposals published as WG I-Ds
OCT 04       Current Roles and Resp submitted to IESG for Info
DEC 04       WG consensus achieved on Change Proposals
FEB 05       RFC 2418bis published as WG I-D
FEB 05       RFC 2026bis published as WG I-D
AUG 05       First WG Last Call on RFC 2418bis
AUG 05       First WG Last Call on RFC 2026bis
DEC 05       RFC 2418bis submitted to IESG for BCP
DEC 05       RFC 2026bis submitted to IESG for BCP

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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 23 Jan 2004 12:11:34 -0800

Hi Margaret,

The charter looks good. W.r.t. the questions, I think it would be best to
keep in the part about changes. We've already gone through one round of just
analyzing the problem (namely the problem group), I think people are ready
to discuss solutions. I also think it would make some amount of sense to
talk about the relation to icar in particular.

            jak

---

From: Pekka Savola <[email-masked]>
Date: Tue, 27 Jan 2004 08:51:04 +0200 (EET)

Comments inline.  Seems to be basically good stuff.

>          responsibilities differ from those documented in RFCs

I've a concern on this.  There seem to be roughly two separate camps 
with completely different beliefs on what the roles inside a WG are.  
It may be a huge challenge (and difficult to the chairs) to gain 
consensus unless that means blocking out input.  But I guess this 
exercise must be done.  The concern is that we get stuck at this item 
forever, and never get any further.

>          should the WG be re-chartered if it decides that
[...]
> considered necessary?  Or include them now?]

I believe re-chartering would be appropriate, as it would keep the
charter and the WG more focused at first, and provide a checkpoint at
the later phase for the community to decide more explicitly whether
these changes are what the IETF in general wants.  However, I don't 
feel particularly strongly about this.

> make changes to the document track or the document approval

I do not think this is necessary.  Maybe you're referring to e.g., the
cases where a new document track might allow a better facilities to
the chairs from the first to assume responsibility (a bit doubtful,
but if a series not requiring IESG approval is introduced, maybe yes),
or that a different document approval process would make this easier 
(which is certainly the case)?

It seems obvious that designing (and approving) those choices are out
of scope.  But I guess what you're asking is whether it would be OK to 
discuss the requirements for such changes in this changes from the 
MPOWR perspective, and then take them to the appropriate other WG(s), 
which I took as an implicit yes.

> WG relates to the ICAR and NEWTRK efforts?]

I do not believe that is necessary -- all the charters will be
available under general area anyway, and folks can read every one of
them separately.  We're not living in a vacuum.  But I would not
object to such language.

> DEC 05       RFC 2026bis submitted to IESG for BCP

The schedule (if we keep the later part of it, that is) could maybe be 
fast-tracked slightly, e.g., FEB, JUN, OCT.  Seems reasonable as long 
as someone is willing to do editing, as we should already have rough 
concensus on the major changes we want to make.

However, what's worrying me a bit is that the first last call outside 
of this WG for these change proposals is in Dec 05.  That's about 2 
years away.  Shouldn't these change proposals be brought to the 
attention earlier, if not using the Last Call procedure, at least by 
presenting them at the plenary and soliciting feedback?  Maybe that's 
a forum of communications which should be explicitly mentioned in the 
charter.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings