I-D ACTION:draft-ietf-problem-process-00.txt

[Margaret Wasserman]

Hi Brian,

At 02:49 PM 5/16/2003 +0200, Brian E Carpenter wrote:
> > 2  IETF Core Values
>
>I'm surprised not to find self-governance listed as a core value.

Explain to me what it is, and if there is agreement, I'll add
it!

>There is a strong implication here that ADs might do this for
>spurious reasons. But if one or both Security ADs are deeply
>convinced that a draft constitutes a major security risk, or one
>or both Routing ADs are convinced that a draft will lead to routing
>loops, isn't it quite appropriate for them to block the document?
>Such cases suggest failures much earlier in the process, not
>misbehaviour by the IESG. So I don't think we should fix this,
>because it is actually a vital back-stop, not a bug.

I agree.  On the poised list, John Klensin suggested some IESG
charter wording that does a much better job of explaining what
should happen than I have.  In particular, he suggested adding
the following wording to the "AD review" process:

"The responsible ADs are expected to complete this review on a
timely basis and, if a significant review period is
required, to make the reasons for the delay public on an
ongoing basis. WGs or document authors or editors may
appeal unreasonable delays to the IETF Chair and, if
necessary, to the full IESG, as described in BCP 9 and may,
on that basis, request that the document be assigned to a
different (or additional) AD."

This is really what I'm trying to say...  The processes
should be changed so that it isn't possible for a document
to get _stuck_ in the IESG (either in AD review or IESG
review) for a lengthy period without a response.

The I-D tracker has helped, because WG chairs can now
detect when this is happening and figure out who to
ask...  But, some things still linger.

BTW, I think that the IESG should retain control of its
own internal processes and consider changes to correct
this, not that the IETF should impose processes on the
IESG.

> >
> >          - Updates to RFC 2418, the Nomcom processes and the IESG and
> >            IAB charters (as needed) to define a more scaleable and
> >            effective organizational structure for the IETF.
>
>I have some difficulty with this. It's inconceivable to me to make
>changes to the IAB charter, or to create an IESG charter, without
>the overwhelming support of the current IAB or IESG respectively. So
>I don't agree that the proposed WG can be "empowered" for this. It could
>be chartered to make concrete proposals to the IAB|IESG but the only
>workable outcome is consensus between the WG and IAB|IESG.

I agree, but others do not.  This disagreement could not be resolved
insider our own editorial team, which is why the current document
contains two different choices for WG oversight.

Once we choose one type of WG oversight to pursue (which I hope happens
fairly soon), it will be easier to make the rest of this section clearer.

> >          - Updates to RFC 2026 and other published processes to build
> >            an effective multi-level standards-track and to reflect any
> >            new organizational roles.
>
>Please specifically exclude updates to IPR policy, since we have just
>reached consensus over in IPRWG not to do this.

This raises sort of an interesting larger question...  We have current
efforts underway regarding our IPR policy (ipr WG) and our Nomcom
process (nomcom WG).  To what extent should the agreements of those
groups be binding on the outcome of this WG?  How would conflicts
between the outcomes of those WGs and the recommendations of the
improve WG be handled?

>A very important step is missing here. All IETF process documents need
>to be formally accepted by the ISOC Board, to ensure that we have the
>necessary chain of authority to validate the liability insurance.

Is this documented somewhere?  If so, let me know and I will refer
to it.  If not, can you explain in more detail how this works and
when the ISOC board enters the process, etc.

Thanks,
Margaret