Ted's insistence that the SPF-classic I-D I'm working is a MARID I-D
has lead me to review the "related" I-Ds.
The following are my comments:
* In the title, it uses the term "Sender ID". During the MARID
process, questions about the existing trademark for Sender ID were
raised and it was decided that the risks to the ISOC and IETF
standards publishing process was too great and therefore the term
should not be used. See:
http://www.imc.org/ietf-mxcomp/mail-archive/msg05042.html
http://www.imc.org/ietf-mxcomp/mail-archive/msg05009.html
I haven't heard anything new on this subject, and I would be shocked
if the DEA set up to review these I-Ds wasn't aware of this issue.
However, I figured I should raise the issue just to be safe.
* There is no support for the HELO identity checking in SPF2.0
records like there is in v=spf1 records. There is no mention of why
this option is not allowed.
* Much of section 1 senderid-core is equivalent to section 1 of
spf-classic. If senderid-core is intended to just update portions
of spf-classic to add the PRA scope, the differences between these
two sections will likely lead to confusion.
* Section 3.1 says that it replaces section 4.5 of the SPF-classic
draft, but does not contain all equivalent semantics. I.e., there
is no mention of what to do when multiple records with the same
version are found. Some of this is later defined in senderid-core
and I think it would be clearer to note that.
* In section 3.3 of senderid-core makes references to spf-classic
section 5, which appears to be incorrect.
* In section 3.3 of senderid-core makes creates the concept of
"positional modifiers", something that SPFv1 lacks. However, this
change in semantics is not restricted to only spf2.0 records.
* In section 3.4 of senderid-core says that SPFv1 records SHOULD be
interpreted as equivalent to "spf2.0/mfrom,pra". This is wrong
since v=spf1 was never designed with the PRA scope in mind, causing
incorrect results and damaging the deployment of SPFv1. It also
omits the HELO scope, which SPFv1 defines.
* Section 4 of senderid-core is largely redundant with section 2.4 of
spf-classic. It is not clear why there are any differences or what
those differences are.
* Section 4.1 redefines the "check_host() function" by adding an
addition argument. No reference to the spf-classic section that
defines the check_host() function is made. No reason is given for
this redefinition and I can find no use for this extra argument.
* Section 4.4 of senderid-core still makes references to zone cuts in
spf-classic, but zone cuts have been removed from spf-classic.
* Section 5 of senderid-core is largely a replacement for section 2.5
of spf-classic, but it redefines certain semantics. These semantics
are not restricted to SPFv2 records only, thus causing compatibility
problems when SPFv1 records are used. It is also not clear why
there needs to be a new, slightly different, set of semantics. I
believe this will lead to confusion.
* Section 6 of senderid-core is largely a duplicate of section 10
of spf-classic. Since the primary difference between SPFv2
(senderid-core) and SPFv1 (spf-classic) is the introduction of the
PRA, and section 6 makes no mention of PRA security considerations,
it is not clear why this section is needed.
* Section 7 of senderid-core is largely a duplicate of section 9 of
spf-classic. Again, the primary difference between these two drafts
is the introduction of the PRA, so it is not clear why this section
doesn't just address the new PRA implications.
All and all, this draft appears to have been written with the
intention that it would reference draft-ietf-marid-protocol, not
draft-schlitt-spf-classic as the former does not have many of the
duplicate sections. Since neither draft-lentczner-spf-00 nor the
draft-schlitt-spf-classic-01 I-Ds were written with the intent that
they would be used by the draft-ietf-marid-* I-Ds, it is not
surprising that these drafts do not dovetail very well.
-wayne