note: I have am not going to respond to Ted's email until I have a
few more things researched and finished up. I'll add some comments
here, just to let people know what I know.
In
<Pine(_dot_)LNX(_dot_)4(_dot_)62(_dot_)0505101811160(_dot_)814(_at_)sokol(_dot_)elan(_dot_)net>
"william(at)elan.net" <william(_at_)elan(_dot_)net> writes:
On Wed, 11 May 2005, Mark wrote to <spf-council(_at_)moongroup(_dot_)com> in
message <200505110046(_dot_)j4B0kE5G099057(_at_)asarian-host(_dot_)net>:
FYI ...
+----------------------------------------------------
| Date: Wed, 11 May 2005 02:38:13 +0200
| From: Ted Hardie <hardie(_at_)qualcomm(_dot_)com>
| To: Mark <admin(_at_)asarian-host(_dot_)net>
| Subject: Re: Clarification on "RFC Editor Note"
| | | Hi Mark,
| As I believe Wayne was told at the time, the
| IESG was considering both draft-schlitt-spf-classic-00.txt
| and the sender-id documents as candidates for
| Experimental RFC at the same time.
This is somewhat correct, although I think it represents a
misunderstanding, possibly on both of our parts.
Late last year, I noticed that the draft-lentczner-spf-00 I-D was
marked for AD Evaluation (or something similar) and I wrote Ted and
informed him that the SPF-council had just been elected and we had
decided to move forward with the draft-schlitt-spf-00 drafts as a
better description of SPF. At no time did I mention SenderID nor
MARID. In Ted's responses, at no time did he mention SenderID nor
MARID. In reviewing things, he did use the plural for things like
"reviews" and "experiments". I think I interpreted that as multiple
reviews of the SPF I-D (IESG and the DEA), and such.
So, it may well have been very clear in Ted's mind that the
schlitt-spf-classic I-D was "part of the MARID set of I-Ds". I can
assure everyone that I considered it to be independent, although I was
aware that the MARID I-Ds were being moved forward at about the same
time and that one of the MARID I-Ds referenced the lentczner-spf I-D.
| [...]
| regards,
| Ted Hardie
It should also be noted that it is strange that Mr. Hardie chose to
focus on the possible incompatibilities of spf-classic-00 to
senderid-core-00, where as the same problem could also be viewed as
that senderid-core-00 may not be compatible with spf-classic-00 in the
way it uses v=spf1 records.
I find this especially strange since the MARID co-chairs/AD directed
the MARID I-D authors to *NOT* use v=spf1 records, but instead use
spf/2.0 records. I'll have to dig up the mxcomp post where they said
that.
(The co-chairs/AD also queried the IETF lawyers about the use of the
term "Sender ID" and the conflict with other trademarks, and the IETF
lawyers came back saying "don't use SenderID in IETF RFCs".)
Please also remind Mr. Hardie that while it is reasonable and expected
for IESG members to make suggestions on how the proposed RFC document
could be improved before it can become an RFC, it would be impolite
and possibly against IETF own policies for IESG to directly make any
changes
to crucial parts of the specification being sent as individual
submission without agreement of the author(s) of the document.
I learned about the RFC editor note by reading the IETF datatracker
web page. No one from the IESG/IETF asked me or told me about it, let
alone asked for my input on the subject.
-wayne