For a change, not a message about SenderKeys :-)
Sender-ID (SPF's heir?) is in "Working Group Last Call". Time to speak
or to shut up for ever :-)
Archives of the Working Group's mailing list are here:
http://www.imc.org/ietf-mxcomp/mail-archive/maillist.html
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
--- Begin Message ---
Today begins a 2 week working group last call for the following
documents:
draft-ietf-marid-core-03.txt
draft-ietf-marid-submitter-03.txt
draft-ietf-marid-protocol-02
draft-ietf-marid-pra-00.txt
To better facilitate discourse, we ask all working group participants
to abide by the following parameters:
1) Messages concerning this last call should fall into one of four
categories: document bugs, technical errors, technical omissions, or
implementation and deployment issues. Each subject line must be
prefaced with a designation stating the category into which it falls.
These designations are "DOC-BUG", "TECH-ERROR", "TECH-OMISSION", and
"DEPLOY".
e.g.,
Subject: DOC-BUG: typos in -core
The co-chairs will not take into consideration messages that do not
meet these criteria. Here are the descriptions of the categories:
DOC-BUG: Document bugs relate to simple errors within the document,
such as typos, bad ABNF, etc... All messages in this category should
be subject prefaced with "DOC-BUG". The author of the message should
note the document bug and provide corrective text.
TECH-ERROR: Technical errors are misuses of technical mechanisms
specified in the document. All messages in this category should be
subject prefaced with "TECH-ERROR". The author of the message should
note the technical error and supply a fix if possible.
TECH-OMISSION: Technical omissions are issues surrounding lack of
needed functionality. An example would be failure to guard against
replay attacks when using cryptographic hashes, etc... All messages in
this category should be subject prefaced with "TECH-OMISSION". The
author of the message should clearly note 1) the goal of the mechanism
lacking the necessary feature, 2) the purpose of the necessary feature,
and 3) a suggested fix to include such a feature while still adhering
to the stated gaol of 1.
DEPLOY: Implementation and deployment issues relate to both technical
and non-technical barriers for the implementation and deployment of the
specifications described in these documents. All messages in this
category should be subject prefaced with "DEPLOY". The author of the
message should clearly state why he/she will personally not be able to
implement or deploy a specification. The author of the message should
not speak on behalf of others. Inclusion of citations supporting a
position will also be helpful: for technical concerns these should be
citations to research or studies, for IPR concerns these should be
citations to legal filings.
2) Discussions of the validity for the need of any MARID solution or
the need for a MARID working group are not appropriate at this time.
While these opinions may be valid, they should be discussed with the
IESG as an appeal for chartering this working group. It is now the job
of this working group to finish the work under its charter and not
debate the validity of the charter.
-MARID Co-chairs
--- End Message ---