On Tuesday, April 01, 2003 4:15 PM, matthew richards
[SMTP:matt(_at_)larkinam(_dot_)com]
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:dhc(_at_)dcrocker(_dot_)net]
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
<paul(_dot_)judge(_at_)ciphertrust(_dot_)com>,
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg