On Sat, 2 Jul 2005, Mark wrote:
Fellow Council Members,
Catching up on my return from the States, I read a lot about being 'fair'
to Microsoft. Though I'm sure the last word has not been said on this
matter, I must say I find this 'equanimity' of the IESG rather puzzling.
It would seem to me, foremost, that if the IESG were serious about a true
even-handed consideration of both proposals, that they would, at the very
least, have asked the infringing party, Microsoft, not to make part of
their own proposal a different, and inevitably conflicting, use of the
v=spf1 records already defined for different usage by the other party, SPF.
Also, the IESG keeps hammering on the SPF and SenderID proposals being
offshoots from the MARID workgroup. Fine. But should the IESG then not
also acknowledge that the upshot of the MARID WG was that SenderID must
use a new record number for its own proposal? Which, to make it clear,
inferred that the reuse of v=spf1 records for SenderID was generally
I entirely agree with and in my opinion SPF Council should do something
about it in normal IETF way. The correct procedure for when you disagree
that certain specification should be published as RFC is:
1. To first launch an appeal with IETF Chair
(email to him personally with CC to general IETF list)
2. IETF Chair may choose to try to resolve the matter individually or
may choose to involve entire IESG. If he does not resolve this to you
satisfaction personally you may also then launch an appeal with IESG.
3. If IESG does not resolve the matter then and only then can the appeal
be launched with IAB (which is a final arbiter)
Note that all appeals are made by individuals but individual may refer
to published document made available by certain organization (i.e. to
SPF council resolution in your case) but he does not have to. In the
appeal most important is to show that proposal would be in conflict with
or against existing widely used internet specification and would thus
cause harm to existing standard. For experimental proposal you mush
show that it would affect not only those who agree to participate in
experiment but others as well and thus could cause harm to the internet
as a whole. If possible references to previous similar cases should be
made and decisions by IESG or decisions made at lower levels at WGs.
In my opinion best avenue of attack against SID are reuse of Resent-
in incompatible manner and reuse of SPF1 records in incompatible manner.
For Resent-* there exist RFC2822 standard so it would be enough to show
that it is against it (although the case is how to interpret the spec)
and for SPF1 you will need to provide references to use of SPF1 prior
to start of MARID (best is to provide link to copy of statistics of
SPF1 use and its adaption rate back then) and make absolutely clear
that MARID group did not proposed any use of spf1 records and worked
on different syntax (i.e. show that Ted's is wrong in his response).
Personally no matter what council decides I'll consider filing appeal
myself, but it'll not happen immediately and I'll likely get to it only
in the middle of July.
I'll strongly suggest filing appeal either at least 10 days before the
IETF conference or if it does not happen then after it (but before in
the next 7-1 days is best), but it must be done within 2 month of IESG
decision if I understand it (and typically appeals happen within few
days or one or two weeks). Note that after appeal is made and email
copy of it is sent to main ietf list, then others can argue for or
against it on the main ietf list and IESG must take that into account
(i.e. it causes something like last-call no matter if athors of the
spec and IESG called for it before or not).
In particular, I find this passage rather bizarre:
Ted Hardie wrote:
You also asked whether the IESG had a position on the re-use
of v=spf1 records. Several members of the IESG were concerned about
the records being used in incompatible ways. Given the history of
MARID, it is clear that both groups using the records can claim
that at various points in history their interpretation was
This wording suggests v=spf1 records were somehow already in existence,
and that two different parties then, at one point or another, gave a
different interpretation to them. Quite a comical rewrite of history, at
that, as v=spf1 records were defined by SPF. Before SPF there were no SPF
records. The IESG position, therefore, that both parties are now somehow
entitled to stake an equal claim to their use is, quite frankly, quite
out of place.
Furthermore, I am disappointed that the IETF has declared that the last
1.5 years of SPF deployment will not count toward the two year requirement
for experimental testing that they have set. Again, to be 'fair' to
Microsoft, since their testing has barely begun. Especially strange, since
the only reason Microsoft reuses existing v=spf1 records, is because SPF
*is* a de facto standard already.
System Administrator Asarian-host.org