RE: [mpowr] Rough Strawman of MPOWR Charter

Your first question is 

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

My first impression is that a good way to do this would be
to create a single working group addressing the issues
of empowerment, standards track, scalability, and 
perhaps other issues.  Within that
working group, this would be one of the projects, so this
would be a "project proposal" rather than a WG proposal.
That way, these closely related subjects could be examined
in a synergistic manner and appropriate RFC's created and/or
modified as needed.  I am sorry that I will not be able
to join you folks in Seoul to consider these questions.

>      (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?]

The WG should be chartered for this up-front.

> 
> [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?]

You have wisely phrased it so that if no change is needed,
none need be done.  As a result, items 3 and 4 definitely
belong, since much of the work necessary to do them (if
necessary) is already included within the charter of the WG.

> 
> [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?]

By its nature, changes in the empowerment of the WGs will
make some kind of changes in the document track and the
document approval process, so such limitations would not
be desirable.

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

There should be explicit liaison activities among these
different activities, since a good idea in one may
solve a problem in another.  It is very important that
the activities divide the work intelligently, since
they are so closely related.  In fact, I would have 
proposed all three of these activities as separate
but closely related projects within a single working group.

I would suggest that you explicitly reference the draft
"draft-ietf-problem-issue-statement-xx" and the related
draft "draft-ietf-problem-process-xx" as source documents
for this work.  That way we will not miss any of the
primary issues, nor will we have to repeat some of the
work in determining the hoped for results of the 
empowerment of the WG.

_______________________________________________
mpowr mailing list
mpowr@ietf.org
https://www1.ietf.org/mailman/listinfo/mpowr