John Glube wrote:
Here's the relevant RfC 2418 text:
| If, at some point, it becomes evident that a working group is
| unable to complete the work outlined in the charter, or if
| the assumptions which that work was based have been modified
| in discussion or by experience, the Area Director, in
| consultation with the working group can either:
| 1. Recharter to refocus its tasks,
| 2. Choose new Chair(s), or
| 3. Disband.
There was _NO_ such consultation with the former working group.
The first question then is what Internet Drafts were on the
table?
draft-ietf-marid-protocol-03
draft-ietf-marid-mailfrom-00
Yes, these drafts were published within days (less than a week)
after a WG Chair (Andy) solicited their submission (2005-09-15,
my local date is 2005-09-17). Only days later (again less than
one week) MARID was closed. I submitted an appeal 2005-09-22.
The total time of "discussion" from the availability of these
drafts to the shutdown of MARID was less than five days. This
included a weekend.
As such, based on the record, in my view the position that
sender policy framework was not before marid is without
merit.
This record is incomplete, to put it mildly. Please add this:
<http://purl.net/xyzzy/home/test/MARID.appeal.txt> Andy, Ted,
and Harald will have no difficulties to confirm that the date
2005-09-22 is correct.
draft-schlitt-spf-classic-02
- and -
draft-katz-submitter-01
draft-lyon-senderid-core-01
draft-lyon-senderid-pra-01
Yes, and one SHOULD in draft-lyon-senderid-core-01 doesn't fly
with v=spf1. Otherwise spf2.0 uses draft-schlitt as some kind
of ersatz-marid-protocol, and as far as I can tell it there's
no other problem with this approach.
They only can't use PRA on v=spf1 policies, anything else might
work within the limits where PRA works at all - how they manage
a "worldwide MSA / MUA upgrade" is certainly no v=spf1 problem.
* Is the statement in the schlitt draft concerning the
recommended usage of SPFv1 records with any other protocol
appropriate?
Yes. On the border to a MUST NOT, but with explicit consent as
by a hypothetical op=pra option a NOT RECOMMENDED describes the
situation more precisely.
However the SHOULD in draft-lyon-senderid-core-01 is incorrect.
The IESG in closing marid stated:
No, this was not "the IESG", it was as you said...
The working group chairs and Area Advisor intend
...Andy, Marshall, and Ted. For another proposal see Scott's
article after the demise of MARID (X-posted to spf-discuss):
<http://article.gmane.org/gmane.ietf.mxcomp/5335>
You and William also discussed in this rather short thread:
<http://article.gmane.org/gmane.mail.spam.spf.discuss/10191>
if the concern is theoretical
No, It's stated in an RfC by Keith Moore, see RfC 3834. It's
stated as an "add Sender if necessary" _option_ in RfC 2476bis,
and "option" means "maybe not" in my book.
It's stated in the famous CYA "Olson objection", I stated it as
the behaviour of an MSA used by me - again and again, here, on
mxcomp, on the general IETF list, in a mail to two IESG members
(published in parts on mxcomp):
<http://mid.gmane.org/42A64C5E(_dot_)5456(_at_)xyzzy(_dot_)claranet(_dot_)de>
It's plain obvious for all Sympa mailing lists. It's a detail
for all moderated newsgroups, it's simply FUBAR. Checking PRA
on v=spf1 without explicit consent does not work. Recommending
it is abuse by MS, and gross negligence by the IESG if they'd
allow it. It's simple enough to explain it to any court of
justice. It's almost on the same "high tech" level as 2+2=5.
* Ask for input from the technical directorate;
For the moment I'd say that I trust that Scott wants to get
it right, but he's busy with tons of WGs (e.g. LTRU + USEFOR).
Bye, Frank
P.S.; The Sympa detail was first mentioned by Meng on mxcomp.
I'm on a Sympa list and confirm it, they use Errors-To.