Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id FAA02084; Thu, 24 Aug 1995 05:36:32 -0400 X-Resent-To: drums@CS.UTK.EDU ; Thu, 24 Aug 1995 05:36:30 EDT Errors-to: owner-drums@CS.UTK.EDU Received: from nameserver.utcc.utk.edu by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id FAA02077; Thu, 24 Aug 1995 05:36:29 -0400 Received: from ester.dsv.su.se by nameserver.utcc.utk.edu (4.1/2.8s-UTK.UTCC) id AA19123; Thu, 24 Aug 95 05:30:00 EDT X400-Received: by /PRMD=SUNET/ADMD=_/C=SE/; Relayed; 24 Aug 95 11:11:03+0200 Date: 24 Aug 95 11:11:03+0200 From: "Jacob Palme DSV-SU/KTH" Message-Id: <1094196*jpalme@su-kom.dsv.su.se> References: <199508240427.AAA09212@wilma.cs.utk.edu> To: ietf-drums Subject: Voting in ietf-drums Your proposal for handling work in ietf-drums sound very reasonable. Perhaps, the vote could be made with a better voting strategy than just yes-no-votes. For example, before the vote, the chairman specifies a list of possible alternative actions, one of which should always be to leave the current text in RFC822 as it is. Participants would then be allowed to vote by setting a score on each alternative according to the following list: 1=Best solution 2=Good solution 3=Acceptable 4=I do not like it, but will not cause major problems 5=Absolutely not, this will cause major problems for implementations I am responsible for (We seem to have a need for a voting standard in IETF. Actually, a project I am involved in in Europe will develop such a standard, which we will propose to IETF in 1997.)