suggestions
Marc Blanchet
Marc.Blanchet@viagenie.qc.ca
Sat, 23 Nov 2002 10:25:17 -0500
--==========3093550493==========
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
-- vendredi, novembre 22, 2002 20:13:42 -0500 Harald Tveit Alvestrand
<harald@alvestrand.no> wrote/a =E9crit:
> thanks Marc!
>=20
> trying to relate your suggestions back to the problems they are meant to
> solve...
Problems were not quite described in length. The engineer in me who go too
fast to the solution without clearly writing the problem... took over...
;-)))
Thanks.
>=20
> --On 21. november 2002 22:26 -0500 Marc Blanchet
> <Marc.Blanchet@viagenie.qc.ca> wrote:
>=20
>> 2. Considerations and Suggestions
>>=20
>> Proposals are numbered in order to pin-point them.
>>=20
>> o WG chairs MUST be formed and know the details of the process.
>>=20
>> P1: new wg chairs MUST attend to wg chair "course" on their
>> first IETF as chairs
>=20
> Problem: WG chairs that do not understand the process cannot use the
> tools available to them most effectively, and may bias or delay the
> outcome of the process.
well described.
>>=20
>> o WG chairs are sometimes busy with their own life/work.
>>=20
>> P2: a wg SHOULD have 2 wg chairs
>=20
> Problem: Groups work very slowly if the chair is not paying attention.
well described.
>>=20
>> o WG charters and requirements are not clear at the beginning
>>=20
>> P3: before wg is started, the charter AND the requirement
>> document SHOULD HAVE reached concensus.
>>=20
>> o Find concensus transparently and efficiently.
>>=20
>> P4: have an online voting tool to help sense concensus on the
>> wg between ietf. I can commit to help set this up if
>> concensus.
>=20
the problem statement for this one is should be reformulated:
Waiting for IETF meetings to identify/reach concensus takes too much time.
Judging concensus
based on mailing list comments does not usually show the silent majority
opinion. Therefore,=20
a fair concensus tool between IETF meetings is required.
> for once, a comment on the proposed solution.... I don't think there is
> any need for consensus in order to *try* this. Just set it up, propose to
> a WG that they use it, and see whta happens.
- we did it in idn.
- it actually helps a lot the wg to move forward. (well, the subject was
pretty contentious, so an IETF meeting concensus pool would have
been as contentious as the one we did in the mailing list)
- however, having a tool already in place for all wg would facilitate a lot
the work of wg.
>=20
> There are lots of little twists around "voting" tools, though....
I know. I have additional sub-ideas on how to do it. If there is some
interest, I can pursue on some req for this tool for IETF use.
>>=20
>> o Pro-active to see in advance issues related to not your area of
>> expertise
>>=20
>> P5: have area experts (i.e. for each area) pre-assigned to
>> each wg. They report to the chairs and AD of the wg, not
>> theirs
>=20
> Problem: The errors in a design that need expertise from other areas to
> catch are caught late in the process, if at all.
well described.
>>=20
>> o Cultivate transparency.
>>=20
>> P6: design teams MUST be avoided.
>=20
> I violently disagree - I think design teams are essential. We should spin
> up a separate thread on what problems they solve.,
Let me explain what I meant. To me there are two cases:
a) a bunch of people write a document, on request of chairs, or wg or AD or
by themselves
b) a design team is started by the chairs or AD or wg and come back later
with a document.
b) has the following weaknesses:
- perception of hidden agenda, of already cooked conclusion, etc...
- during the design team work, somewhat the wg is "stalled" waiting for
the outcome. You are always free to comment on the mailing list, but
usually, when a design team is working on the subject, the subject is
somewhat closed until resolution of the design team.
- also the selection process of members is usually behind the scenes.=20
- these descriptions above come back to transparency (or better said:
perceived lack of transparency and openness)
I have the experience of design teams with idn. They worked well, worked
hard, produced good results. However, I hear, as a co-chair, a lot of
comments of lack of transparency, even if all the design team members were
in good will and working for the "cause". If it happens again as a
co-chair, I would instead just ask some guys to draft a document on the
subject and send it to the list. The fact that they could by themselves
meet together, create a mailing list for their own work, etc... is ok. The
main difference is that from the process perspective, it is much more
opened and transparent than the design team way.
In fact, we are acheiving exactly the same goal, the same objectives. The
only difference is the formal process used. I'm against the "formal" design
teams, but I'm for any collaborative work done in their own separate
thread.=20
In other words, there should be only one thread in the wg. All other
threads should be owned by individuals, not children of the wg thread...=20
At the minimum, if the community still want to keep design team (which
again I'm opposed essentially for transparency reasons), we should draw
more specific guidelines on what can be done and not. At least, RFC2418
should be updated with some more specific guidelines to ensure transparency
for design team. I won't suggest any for now since I would prefer that we
kill them and will try hard to convince the community. ;-))
>>=20
>> P7: interim meeting should not happen unless a significant
>> portion of the wg confirmed presence.
>=20
> I find this problematic, both in theory and practice. For one thing, you
> won't know how many confirm presence before the pratcical details are
> done. Then it becomes messy to cancel.
I know it is difficult. And rereading myself, it was not the right problem
statement, nor the right solution. The real problem to me is about
legitimacy, if people cannot come that would otherwise come.
The problem statement should have been:
- Interim meeting are often called with not enough notice in advance with
the important information needed: agenda, location, dates. This results in
important scheduling problems for people to attend the meeting.=20
Let me redesign the solution, based on the better described problem
statement.
P7: interim meetings should be called with sufficient advance notice (1
month min.) that includes the intended agenda, the location and the dates.=20
>>=20
>> P8: have a formal tracking system to track document comments.
>=20
> Problem: Some comments are lost without being addressed by document
> authors. It is hard for others to see what outstanding comments there =
are.
> (AAA seems to have had a wonderful help from their system....)
well described.
>>=20
>> P9: any room concensus MUST use hands not humms. Questions
>> MUST be written on the screen
>=20
> Problem: Sometimes a WG does not know what it is polling on, and
> sometimes it is hard to tell whcih of several alternatives have stronger
> consensus.
>=20
well described.
>>=20
>> o We are a world organization which bridges languages and cultures
>> and egos
>>=20
>> P10: Chairs and proposers MUST write questions/proposals/...
>> on the screen before any discussion
>=20
> Problem: Non-English speakers find it easier to read questions from a
> screen than to be sure they understand a spoken question.
well described.
>>=20
>> P11: If a wg chair or AD is an author of a wg doc, he should
>> find a co-author and have his co-author make presentations.
>>=20
> Problem: <not sure how to formulate this>
Problem: The chairs and ADs might be seen to use their status for pushing
their own documents or proposals.
Thanks a lot for clarifing problem statements. Attached is a new version of
the draft based on your comments and my response.
Marc.
--==========3093550493==========
Content-Type: text/plain; charset=us-ascii;
name="draft-blanchet-ietf-evolutionize-suggestions-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="draft-blanchet-ietf-evolutionize-suggestions-01.txt"; size=8937
Internet M. Blanchet
Internet-Draft Viagenie inc.
Expires: May 24, 2003 November 23, 2002
Suggestions to Streamline the IETF Process
draft-blanchet-ietf-evolutionize-suggestions-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 24, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The intent of this document is to document problems in the IETF
process and to suggest simple solutions that can be easily
implemented and do not require major changes in the IETF
organisation, following the value of "running code".
1. Use of keyword
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Blanchet Expires May 24, 2003 [Page 1]
Internet-Draft Suggestions to Streamline the IETF Process November 2002
2. Considerations and Suggestions
This first version of this document was written during the
presentations of the Atlanta ietf plenary on the subject of
evolutionizing the IETF. It started with the author personal views
of problems and solutions and then was revised based on feedback.
The document is structered in the following way: for each problem, a
problem statement is described and one or many solutions are listed.
Problem statements are labeled and numbered with P## and suggested
solutions with S## in order to identify them when discussing.
Numbering spaces are independant each other and are not ordered in
any specific way.
o P1: WG chairs that do not understand the process cannot use the
tools available to them most effectively, and may bias or delay
the outcome of the process.
S1: WG chairs MUST be formed and know the details of the
process. New wg chairs MUST attend to wg chair "course" on
their first IETF meeting as chairs
o P2: Groups work very slowly if the chair is not paying attention,
like WG chairs are sometimes busy with their own life/work.
S2: a wg SHOULD have 2 wg chairs
o P3: WG charters and requirements are not clear at the beginning
S3: before wg is started, the charter AND the requirement
document SHOULD HAVE reached concensus.
o P4: Waiting for IETF meetings to identify/reach concensus delays
too much the advancement of the working group. Judging concensus
based on mailing list comments does not usually show the silent
majority opinion.
S4: A fair concensus tool between IETF meetings is required.
An online voting tool to help sense concensus on the wg between
ietf.
o P5: The errors in a design that need expertise from other areas to
catch are caught late in the process, if at all.
S5: have area experts (i.e. for each area) pre-assigned to
each wg. They report to the chairs and AD of the wg, not
theirs
Blanchet Expires May 24, 2003 [Page 2]
Internet-Draft Suggestions to Streamline the IETF Process November 2002
o P6: Lack of transparency: design teams are perceived as a way to
bypass the wg, to push forward the design of their members.
Design team member selection is often done behind the scenes.
S6: Instead of using design teams, chairs ask many individuals
to write a document on the subject matter.
o P7: Interim meeting are often called with not enough notice in
advance with the important information needed to schedule: agenda,
location, dates. This results in important scheduling problems
for people to attend the meeting.
* S7: interim meetings should be called with sufficient advance
notice (6 weeks min.) that includes the intended agenda, the
location and the dates.
o P8: Some comments are lost without being addressed by document
authors. It is hard for others to see what outstanding comments
there are.
* S8: have a formal tracking system to track document comments.
o P9: Room concensus request are often unclear and do not give good
results.
* S9: any room concensus MUST use hands not humms. Questions and
choices to vote MUST be written on the screen and the meaning
being verified and agreed before proceeding to the concensus
pool.
o Non-English speakers find it easier to read questions from a
screen than to be sure they understand a spoken question.
S10: Chairs and proposers MUST write questions/proposals/...
on the screen before any discussion
o The chairs and ADs might be seen to use their status for pushing
their own documents or proposals.
* S11: If a wg chair or AD is an author of a wg doc, he should
find a co-author and have his co-author make presentations.
3. Security Considerations
If we don't streamline the IETF process, we might end up either:
doing too late standards to secure the Internet or pushing bad
unsecure protocols.
Blanchet Expires May 24, 2003 [Page 3]
Internet-Draft Suggestions to Streamline the IETF Process November 2002
4. Acknowledgements
All the people, in particular Thomas Narten, Erik Nordmark, Harald
Alvestrand, John Klensin, James Seng, as well as many others, that
have been involved in the idn working group and helped me to learn to
try to be a wg co-chair are acknowledged here.
The new revisions of the documents were made based on suggestions
from: Harald Alvestrand.
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Marc Blanchet
Viagenie inc.
2875 boul. Laurier, bureau 300
Sainte-Foy, QC G1V 2M2
Canada
Phone: +1 418 656 9254
EMail: Marc.Blanchet@viagenie.qc.ca
URI: http://www.viagenie.qc.ca/
Blanchet Expires May 24, 2003 [Page 4]
Internet-Draft Suggestions to Streamline the IETF Process November 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Blanchet Expires May 24, 2003 [Page 5]
--==========3093550493==========--