Re: [mpowr] Rough Strawman of MPOWR Charter

["James Kempf" <[e-mail]>]

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

----- Original Message ----- 
From: "Margaret Wasserman" <[e-mail]>
To: <[e-mail]>
Cc: "Thomas Narten" <[e-mail]>
Sent: Friday, January 23, 2004 9:45 AM
Subject: [mpowr] Rough Strawman of MPOWR Charter


>
> 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 <[e-mail]>
>
> General Area Advisor:
> Harald Alvestrand <[e-mail]>
>
> Mailing Lists:
> General Discussion: [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mpowr
>


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