[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-iesg-charter-02.txt
Hi All,
I have a few substantive comments on the IESG Charter document.
I sent these comments to Harald privately (along with a long list
of editorial comments), because I did not want to send them
on a public list, and Harald suggested that this list would represent
a good compromise between public and private for this discussion.
First a comment on what's not in the document:
The document currently omits the role of the IESG in the appeals
process.
Now some comments on the document text:
At the time of this writing, the liaisons present represent the
following bodies:
I have looked in other process documents, and I have not found
any process for adding/removing liaison positions. Is this something
that can be done by IESG consensus, whenever the IESG believes that
a change is needed? If so, I think that this document should say so.
Normally, there will be communication with the community of interest
for the working group too.
This should be stronger, IMO.
A charter is a contract between the WG and the IETF, negotiated by
the IESG (for the IETF) and the WG chairs (for the WG). So, the
WG should be involved in the discussion, as should the IETF (through
the comment period). This also applies to re-charters.
All charters for proposed working groups are announced to the
community at large before the IESG makes a decision.
In reality, the IESG has to conditionally approve a charter before it is
announced to the community, right? A proposed charter can be rejected by
the IESG without a community announcement.
Shutting down a WG is a decision of the responsible AD.
Do you think that anything should be said here about fairness,
communication with the WG, communication with the WG chairs,
consultation with the rest of the IESG, etc? Because that type
of wording is included elsewhere, it's absence is noticeable
here.
4. The IESG role in document review
4.1 Working group documents
This role is described in RFC 2418 section 7.5, and RFC 2026 section
6. The IESG role is one of review and approval.
Since this section represents the bulk of the IESG's work, both
in terms of time and importance, I think that more than two sentences
are called for here.
[I have tried _really_ hard not to be intentionally inflammatory
in the following comments. Please also note that I did not send
these comments on a public list. It is my intention to engage in
a constructive dialogue with the IESG, not to incite public unrest.]
The current wording very much understates the role that the IESG
currently plays in the WG document process. I would also argue that
the IESG's current processes are not in-line with RFC 2418, section
7.5 and 8. This is one of the areas where I believe that the IESG has
imbued individual ADs with authority that does not derive from any
community-approved document.
I consider this to be a substantive and important issue regarding the
fairness and openness of the IETF document process. I also think that
the current situation undermines the authority and empowerment of WG
chairs, and contributes to (or at least enables) a laissez faire attitude
on the part WG chairs, document authors and WGs. Note that I did not
say that this situation is the only cause, or that it excuses lax
practices, only that it is a contributing factor.
In particular, I am talking about the "AD review" process that
happens before a document is sent to the IESG, and about the
"DISCUSS" process that occurs during IESG review.
RFC 2418, section 7.5:
"Once that a WG has determined at least rough consensus exists within
the WG for the advancement of a document the following must be done:
- The version of the relevant document exactly as agreed to by the WG
MUST be in the Internet-Drafts directory.
- The relevant document MUST be formatted according to section 7.3.
- The WG Chair MUST send email to the relevant Area Director. A copy
of the request MUST be also sent to the IESG Secretariat. The mail
MUST contain the reference to the document's ID filename, and the
action requested. The copy of the message to the IESG Secretariat
is to ensure that the request gets recorded by the Secretariat so
that they can monitor the progress of the document through the
process.
Unless returned by the IESG to the WG for further development, progressing
of the document is then the responsibility of the IESG. After IESG approval,
responsibility for final disposition is the joint responsibility of the RFC
Editor, the WG Chair and the Document Editor."
RFC 2418, section 8:
"The IESG reviews all documents submitted for publication as RFCs.
Usually minimal IESG review is necessary in the case of a submission
from a WG intended as an Informational or Experimental RFC. More
extensive review is undertaken in the case of standards-track
documents.
Prior to the IESG beginning their deliberations on standards-track
documents, IETF Secretariat will issue a "Last-Call" to the IETF
mailing list (see [1]). This Last Call will announce the intention of
the IESG to consider the document, and it will solicit final comments
from the IETF within a period of two weeks. It is important to note
that a Last-Call is intended as a brief, final check with the
Internet community, to make sure that no important concerns have been
missed or misunderstood. The Last-Call should not serve as a more
general, in-depth review."
Review by the IESG then leads to one of 5 actions, all outlined in
RFC 2418, section 8. These actions include: accepting the document,
suggesting changes to the author(s)/WG or rejecting the document.
And RFC 2096, section 6.1.2 says:
"In a timely fashion after the expiration of the Last-Call period, the
IESG shall make its final determination of whether or not to approve
the standards action, and shall notify the IETF of its decision via
electronic mail to the IETF Announce mailing list."
By my reading, these documents indicate that a WG chair sends a
document that meets WG consensus to the IESG for consideration (with
a possible check to make sure that the I-D is properly formatted),
that an IETF-wide last call will be sent soon after the request
is received, and that the IESG will review the document and make a
timely determination after the IETF-wide last call is completed, with
some public output from that review -- acceptance, rejection or a
"clear and direct" set of suggestions to the WG.
If suggestions are sent, the WG can try to convince the IESG that they
are incorrect. Or, the WG can make changes to the document (through
the usual WG editorial/consensus process) and re-submit the document
for IESG consideration. This would involve another letter from the
chairs to the AD/secretariat, another IETF Last-Call, etc.
I've tried not to misleadingly quote these documents out-of-context,
but please read the originals and let me know if I've misunderstood
something.
Our current process is very different from this...
[I realize that our current process has evolved over time to try to
correct problems, etc. However, I think we have moved (slowly
perhaps) pretty far away from the original process described in
RFCs 2418 and 2026.]
The WG writes a document that represents WG consensus, and the chair
sends a message as described. But, the document does not go to the
IESG, and no IETF-wide last call is started. At that point, the
document enters AD review -- an often lengthy process of negotiating
the document with the "responsible AD", in order to convince that
AD to actually send the document to the IESG and to initiate a
last call. Is there any document that gives the responsible AD
this authority?
As far as I can tell, the IETF standards and WG process documents
don't even acknowledge the existence of this stage of processing, and
yet some documents seem to get stuck in this stage for a long time.
It is common for this stage of the process to take months, and it
sometimes takes more than a year.
The discussions in this stage are not usually open (i.e. they
tend to occur privately between the responsible AD and the chairs
and authors), and the WG is not fully involved in any changes that
are made at this point. Although the WG is usually informed of
changes made at this stage, there is no real process for determining
if the changes meet WG consensus. The WG doesn't have any real
choice about making the changes, as the document is, effectively,
held hostage in this stage until the responsible AD decides that
the document is suitable to send to the IESG.
Because this stage doesn't actually exist from a process standpoint,
there are no guidelines for what the criteria should be for
acceptance, there are no limits on the amount of time that this
can take, there is no clean yes/no decision at this point, and there
is no applicable appeals process.
If it is the position of the IESG that this is a reasonable and
effective level of authority for a WG's "responsible AD", I think that
should be called out in this document, and subject to community
discussion. Also, the authority of the AD should be limited in
some way and/or the responsibilities for timely and open response
should be outlined.
There is a further problem, IMO, with how the IESG reviews
documents -- the "voting" procedure, particularly the "DISCUSS"
vote. Again, this procedure grants authority to a single AD that
is not explicitly granted by any process documents, and the process
of resolving these issues is not sufficiently open.
The process documents, quoted above, indicate that the IESG will
review the document and will return one of five answers in a
timely manner on a public mailing list. It does not say how the
IESG should arrive at this answer, so it does make sense for the
IESG to have an internal procedure to make that determination.
While I would prefer a consensus-based (or two-thirds majority
based) determination, there is nothing in the process documents
that forbids the IESG from requiring unanimity.
However, the IESG's current internal procedure does not match
with the process described in RFC 2418 and 2026. A document can
be stalled in the IESG by a DISCUSS vote for an arbitrary period
of time, without the IESG publicly stating a response on the IETF
mailing list and providing "clear and direct" suggestions to
the WG.
While the document is held in a "DISCUSS", another round of private
discussion is held between the responsible AD, WG chairs and authors,
and further changes are made that do not necessarily reflect the
consensus of the WG. This process is much less open and less
driven by WG consensus than the process described in RFCs 2418 and
2026. Instead, the current process document indicate that the
IESG should publicly return the document to the WG with "clear
and direct" suggestions, and the WG should determine how to
handle those suggestions.
IMO, the slowness/serialization of the current process, the
exclusion of the WG from the "responsible AD" and "DISCUSS"
discussions, and the fairly open contempt in which some members
of the IESG hold some large WGs has done much more to damage the
effectiveness and reputation of the IETF, and to damage the
technical quality of Internet standards, than would have been done
by publishing documents more quickly with fewer modifications.
I'm not even sure, in all cases, that forcing the modification
of IETF documents to meet the acceptance criteria of every
individual IESG member substantially improves document quality.
5. The IESG role in area management
The IETF divides its work into a number of areas, each comprising
working groups that relate to that area's focus. (RFC 2418 section
1). The area structure is defined by the IESG, and the IESG can add
areas, redefine areas, merge areas or close down areas. The IESG
decides which areas groups belong to.
Is there a document anywhere that indicates that the area structure
is defined by the IESG?
If there is no other reference, I think that you should say more
about how/when the IESG can change the area structure. There are
two major options, I guess:
1) The IESG has the authority to change the area structure
whenever it feels it would be useful to do so.
2) Changes to the area structure are determined by IETF
consensus, and it is the responsibility of the
IESG to solicit and judge that consensus.
The IESG attempts to reach all decisions unanimously.
Why? Is there a document that requires or suggests this? IMO,
this is another situation where the current IESG processes give
more authority to a single IESG member than is required or
advisable.
Also, this conflicts with a similar statement in the "procedures"
document (draft-iesg-procedures-00.txt), which says:
"The IESG attempts to make all its decisions by consensus."
If unanimity
cannot be achieved, the chair may conduct informal polls to determine
consensus. The IESG may make decisions and take action if at least
two thirds of the members concur and there are no more than two
dissents.
This is new and very welcome. Is it intended that this will be used
for document actions moving forward?
And, why "more than two dissents"? Why not just a straight two-thirds
majority (which could have four dissents at the current size of the
IESG)?
7.2 Openness and confidentiality
The IESG publishes minutes of all its meetings on the Internet,
It would be much better (in terms of openness) if the IESG published
real minutes of the discussion, instead of just decisions. Also, is
there a reason why the IESG mailing list archives are not publicly
accessible? There could be a "confidential" list that is used
only for confidential legal and/or personnel activities.
Thank you for your time and consideration.
Margaret