Re: ID ACTION:draft-ietf-iesg-wgguidelines-00.txt Thu, 14 January 1993 18:41 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa25670; 14 Jan 93 13:41 EST
Received: from MITCHELL.CIT.CORNELL.EDU by IETF.CNRI.Reston.VA.US id aa25660; 14 Jan 93 13:41 EST
Received: from MITCHELL.CIT.CORNELL.EDU by (4.1/1.34/Honig-1.3) id AA11825; Thu, 14 Jan 93 13:42:16 EST
Message-Id: <>
To: poised@IETF.CNRI.Reston.VA.US
Cc: iesg@CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
Subject: Re: ID ACTION:draft-ietf-iesg-wgguidelines-00.txt
In-Reply-To: Internet-Drafts@CNRI.Reston.VA.US's message of Wed, 13 Jan 1993 10:15:56 -0500. <9301131015.aa05258@IETF.CNRI.Reston.VA.US>
Date: Thu, 14 Jan 1993 13:42:15 -0500

Hi.  In the following, are you trying to say that it is not possible to
hold a closed "working group" meeting, that only "executive sessions"
can be closed?  I detect a definition of the membership of a working
group to be "whoever shows up".  This is certainly the trend but is not
necessarily the best thing.  My experience is that the best working
groups have always had a clearly defined core membership which is
committed to the project, and that while others can come to meetings
that this doesn't make them members of the WG.  My favorite mode for
serious working groups is sort of "systolic" in which closed and open
meetings alternate.

  >5. It is acceptable to have restricted participation (not attendance!)
  >   at IETF Working Group meetings for the purpose of achieving
  >   progress. The Working Group chairman usually has the authority to
  >   refuse to grant the floor to any unprepared individual. 

Further comments ...

  >8. Repeated discussions on the same issues over E-mail can be avoided
  >   if the chair makes sure that after a discussion has come to a
  >   conclusion, the main arguments in the discussion (and the outcome)
  >   are summarized and archived. It is also good practice to note
  >   important decisions/consensus reached by E-mail in the minutes of
  >   the next 'live' meeting.

It is also very important that any published documents, i.e. internet
drafts and standards, contain a discussion of what alternatives were
rejected and the main reasons why.  The memory of the IETF isn't very
good -- we *have* to get our reasoning written down.

  >-  The relevant document has to be formatted according to RFC-rules 
  >   (see RFC-1111 [4]). 

Except this one, of course ;-).