Subject: RE: [Asrg] voting?

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 1 Apr 2003 18:48:40 -0500

On Tuesday, April 01, 2003 4:15 PM, matthew richards [SMTP:[email-masked]] 
wrote:
> i've read many good proposals that have potential and are then
> consequently lost in the fray of new posts, technical nit picking,
> and cat fights.

That is true, however a consensus call on proposals presupposes a definitive 
set of requirements and terminology.  I am new to the list, and have been cull 
the archives and discussions for the last few days.  Certainly, one of the 
first points I offered was that the requirements did not appear to me to be 
defined (although I found out subsequently that a group of goals was being 
worked on) so I 'volunteered' - according to someone :-) to work on the list of 
requirements.

A list of requirements in this a technical forum must be, to quote a message 
from that thread "cost vs. benefit":

On Saturday, March 29, 2003 12:18 AM, Dave Crocker [SMTP:[email-masked]] 
wrote:
[Requirements] need to talk in terms of high-level behavior of the
system, rather than providing requirements for implementation details.
Therefore they need to be general.  However if they are too general,
they have no meaning.

So for the past few days that is the task I have been monitoring and trying to 
tackle by participating (where I can) and soliciting information on the 
consensus or merely 'thinking' on some of the issues.  So far a paper-man of 
requirements has emerged, but there is (quite) a bit more to go before I can 
present a draft.

The draft of requirements ToC will include information (I suggest if anyone has 
any advice or wants to help now would be as good a time as any) on requirements 
in the following formats:

Section #. Requirement
Section #.1 Requirement Rationale
Section #.1.1 Scenario (optional)

I will not use the RFC2119 the convention for keywords, but will flow with 
consensus as follows:

"  keywords MUST, MUST NOT, SHOULD, and MAY are NOT as in RFC 2119,
   but rather:

   o  MUST: This word, or the terms "REQUIRED" or "SHALL", means that
      the described behavior or characteristic is an absolute
      requirement for a proposed ASRG specification.

   o  MUST NOT: This phrase, or the phrase "SHALL NOT", means that the
      described behavior or characteristic is an absolute prohibition of
      a proposed ASRG specification.

   o  SHOULD: This word, or the adjective "RECOMMENDED", means that
      there may exist valid reasons in particular circumstances for a
      proposed ASRG specification to ignore described behavior or
      characteristics.

   o  MAY: This word, or the adjective "OPTIONAL", means that described
      behavior or characteristics are truly optional for a proposed ASRG
      specification.  One proposed specification may choose to include
      the described behavior or characteristic while another proposed
      specification may omit the same behavior or characteristic.         "

> it would be nice if this list had some kind of executive structure-
> maybe we could elect some "officials" who could manage the threads
> and make critical decisions.

The parties responsible for starting the Research Group (RG) have that 
responsibility  however:

"IRTF experience suggests that these roles typically cannot all be handled by 
one person; at
least four or five active participants are typically required.  To help in this 
determination, a proposal to create a Research Group should include a list of 
potential charter members."[RFC2014]

I do not know the status of the chartering membership (perhaps we are it ;), 
the chair of the Anti-Spam RG is Paul Judge <[email-masked]>, 
though that may have changed, IDK. In addition since the work of this group and 
the group itself should be long lived:

'In particular, an IRTF Research Group is expected to be long-lived, producing 
a sequence of "products" over time.  The products of a Research Group are 
research results that may be disseminated by publication in scholarly journals 
and conferences, as white papers for the community, as Informational RFCs, and 
so on.  In addition, it is expected that technologies developed in a Research 
Group will be brought to the IETF as input to IETF Working Group(s) for 
possible standardization.'

You should anticipate a number of on-going debates that result in some work 
product from the individual participants and contributors to this group. 
 Though some of the IRTF RGs may have limited membership according it is not 
encouraged unless it is deemed necessary to for stable long term relationships. 
 This also highlights the difference between the IETF Working Group (WG) 
activities 'standards setting' and the research of the RGs.  "Even more than 
the IETF, the work of the IRSG is expected to be marked by informality.  The 
goal is to encourage and foster valuable research, not to add burdensome 
bureaucracy to the endeavor."[RFC2014]

Research Groups are guided by procedures and guidelines for work based on 
[RFC1603]

> i.e. as a group the ASRG will probably never come to a consensus as
> to the definition of spam (or even if we need an absolute definition)
> i think we do, and i think other members of this list probably agree;
> a vote or poll could determine the majority consensus (and establish
> essential keystones from wich further constructive efforts could be
> launched)- this could give the form greater focus, and make it
> possible for the work items to actually be accomplished! as opposed
> to endless wild threads fraying off into infinity.

Since the March 1 start of the archives you are correct in stating that the 
conversation and ideas have been fast and furious.  Giving this a perspective 
is important this is not an IETF WG where we are focused on a solution in an 
engineering context, this group is 'researchy' so it is looking at possible 
solutions from a methodological context (IMHO).

Although we may come up with some great idea to save the world from 'spam' that 
is not necessarily the 'task' that is set out.  Think of it as cancer research, 
you may find the cure you may not but you will almost certainly learn a lot 
more about cancer and cell growth and other dynamics of the systems involved. 
 That research product may then be used to develop a vaccine, use as a 
diagnostic or even be the basis for a cure.

> take a look at what's been posted so far- have we accomplished
> anything? all i see are a bunch of concentric circles, or maybe
> circus rings. what good ideas do surface are not empowered to stay
> afloat and eventually sink back down into the sediment. if that
> doesn't change, realistically how can we ever hope to accomplish
> anything?

I understand the frustration, many years ago I remember joining an IETF working 
group to talk about the development of a new network layer protocol (this was 
waaay before IPv6) among many other proposed 'solutions'.  My chosen one was 
called TUBA, it lost out, but I didn't I benefited from the dynamic exchanges 
and workings within the group's dynamic (Thanks DC :-).

I participated in all of the working groups involved SIPP, PIP, etc. (they were 
all over the map with acronyms) but the fundamental problem was addressed and 
eventually (hopefully) solved.  Perhaps during or before that time an IRTF RG 
would have been instrumental in finding methodologies that would have been more 
sensitive to the implications of stop gaps (or that's what we thought they 
were) that emerged.

To me this forum is the proper complement to the IETF process (which I still 
participate in of course).  Also, I think eventually active participants will 
take on some of the burden of guiding pet projects or ideas that address the 
research topics involved.  Currently these are the active thread as I see them:

	Requirements Development (over arching thread)
	Terminology and Definitions
	Metrics
	Constraints (over arching thread)
	Related work

the others are discussions of various methodologies for a solution or are di  
scussions of subsets that are part of a solution.  I am not clear on whether a 
consensus call is advised at this point until we have a basis for objective 
evaluation.  A lot of the 'proposals' look interesting, so it will be hard to 
develop any consensus with out a common point of reference.

-e

---
[RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and
          Procedures", RFC 2014 (BCP 8), October 1996.

[RFC1603] Huizer, E. and D. Crocker, "IETF Working Group Guidelines and
          Procedures", RFC 1603, March 1994.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg