ietf-mxcomp
[Top] [All Lists]

Re: Appeal: Publication of draft-lyon-senderid-core-01 inconflictwith referenced draft-schlitt-spf-classic-02

2005-08-27 20:27:28

william(at)elan.net wrote:

SPF aims at stopping spoofing of RFC2821 MAILFROM address
and to prevent backcuster of delivery failure messages when
address is misused.

Yes.  (I've reduced the X-posts to mxcomp - maybe a bad idea)

with two conflicting specifications it is difficult to
understand what the intent of the sender is. This is a
problem for both SID and SPF protocols and unless resolved
it discourages participation of users in these experiments

Good point, unreliable results are also bad for PRA checks.

the technical people from Microsoft participating at MARID
were not at all responsible for it, they were victims of the
decisions made quite deep at their company

IBTD, they are listed as "inventors" in the patent application
<http://tinyurl.com/6lczr>.  I doubt that this happened against
their will - okay, with all this "opt-out" madness everything
is possible, but for a patent the lawyers would try to avoid
all formal problems.

difficult to come to consensus, although if given time to
cool down it could have been possible, but you can see this
difficulty even now with SPF and SID drafts

The consensus to separate SPF from PRA, or rather MAIL FROM
from PRA putting aside HELO for later, was IMHO very clear.

When Mark was asked to create marid-mfrom-00 (and did within
less than a week) I really thought that the WG would finally
start to do something productive instead of XML-over-DNS,
dubious 2822-PRA constructs, and IPR issues.

But three days later it was closed.  The first process failure
in this saga, or rather the second, discussing CID / SID at all
instead of the clean LMAP proposals was already desastrous:

The ASRG is essentially dead since Yakov resigned, one day
after CID was pushed on the LMAP stack as surprise-MARID-input.
 
he assumed himself to be appropriate representative of
open-source-like group that created SPF and that he could on
their behalf continue to talk and work further with MS

Meng published "an apology for Sender-ID" as I-D, at this time
he knew well that "unified SPF" did not represent the wishes
of the community,  He proposed v=marid as clean way to solve
the "Olson objection".  Not sure about others, but I accepted
the latter.  I never had a problem with the idea that those
who _explicitly_ want it should get PRA, it's their mail.

It would be nice to know what happened behind the scenes.

At least the MARID Jabber logs are public, the last two are:
<http://www.xmpp.org/ietf-logs/marid(_at_)ietf(_dot_)xmpp(_dot_)org/2004-08-04>
<http://www.xmpp.org/ietf-logs/marid(_at_)ietf(_dot_)xmpp(_dot_)org/2004-09-20>

what you see here is an example of why IETF standardization
work should be done in public instead of private.

Tricky to get the WG Charter right.   I'm still surprised that
LTRU actually produced something, in that case it worked well.

For DKIM I'm less confident.  Maybe if Dave adopts some ideas
from among others Doug and Earl - that false promises and hype
are a trap should be clear after SPF, "we" cleaned the field
by testing most errors. ;-)

they really do need to be viewed as separate individual
submissions and should be judged on their own merits.

True.  But there's nothing wrong with spf2.0 reusing the ABNF,
protocol, error handling, processing limits, SPF RR, etc. of
v=spf1.  If they're lazy enough they can even reuse the rather
obscure Received-SPF, unlike Authentication-Results that's at
least in a shape which _might_ survive Bruce's^Wan IETF review.

SPF draft is best attempt so far to document SPF protocol as
it was developed prior to MARID (with only few things
borrowed from MARID)

ACK, mainly it adopted revolutionary ideas like "ABNF must pass
Bill's parser" and all the other formal nits... <eg>  Okay, it
also reduced Doug's imaginary "thousands of DNS queries" to now
only "hundreds".  Or in other words roughly ten for the worst
non-attack case.

 [senderid]
as separate submission made to IETF, it should also be
responsibility of IESG that their proposal does not come
into conflict with other LMAP proposed experiments and does
not break any other IETF standards.

Indeed.  

please understand that v=spf1 document does not represent
MARID work perse

Of course not.  After MARID was closed Mark proposed to resume
the work on v=spf1, the community decided to follow this plan.

slightly further developed and better documented (with that
documenting being in part result of working at MARID).

The RfC is _much_ better than the last pre-MARID draft.
 
I believe at this point the appeal is only to IETF chair and
not to IESG.

Pardon ?  AFAIK there are only four appeal levels, to the AD
in the case of a WG, to IETF Chair in the case of the IESG, to
the IAB in the case of a process failure, and finally ISOC.

now only one person from IESG has opportunity to overrule
them.

Are you sure ?  Where can Brian overrule the IESG ?  He's only
the primus inter pares, the AD of the general area.  Like our
SPF Council Chair.

The appeal is only against SID draft

It's only against four letters in this draft from my POV.

SPF draft should continue to be viewed as separate submission
and decided on its own merit.

Of course, as you see in the tracker that's precisely how it
was handled.

As far as MARID work IESG wanted, the correct thing is start
working on SPF2/3 where we left off at MARID

If the IESG would have "wanted" any further MARID work they'd
not have closed this WG, don't you think ?  IMHO they want as
less as possible to do with MARID.  Even in the course of my
aborted MARID appeal it was clear (from my POV) that reviving
MARID after its sudden death was and is no option.

SPF is a free and open project, we now have our own elected
Council.  I'm not interested to exchange it against the IESG.
We tested this approach here in MARID, it failed, forget it.

If XMPP can do it, SPF can also do it, and if it doesn't work
we're at least sure that it's our own fault, and not some big
player pulling strings in backchambers.

SPF community agrees to soften v=spf1 draft and allow for
use of positive results with other identities

Over my cold and dead body, pseudo-PRA-PASS phishing is ugly.

We can offer op=pra opt-in, time to publish this as I-D when
needed about 60 seconds.  For "we" read SPF-TINW, not IETF-we.

                          Bye, Frank