spf-discuss
[Top] [All Lists]

Re: FW: Clarification on "RFC Editor Note"

2005-05-10 19:36:53

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.  That statement in
| the spf-classic draft would have created an RFC 2119
| statement that the other Experiment shouldn't be run.
| That was contrary to the decision taken at the end of
| MARID (that both should be documented as Experimental
| and further work await experience with the experiment).
|                        regards,
|                                Ted Hardie


SPF Council,

Having read Mr Hardie's response, I believe he may have misunderstanding regarding concerns of the people involved in SPF Community and has incorrectly assumed that we're trying to interfere with somebody else's experiment and trying to prevent it from running.

I believe the position expressed by overwhelming majority of those at SPF-discuss list during last 6 months is rather that we want to make sure the experiments do not interfere with each other and that experiment (as all experiments do!) involve only the people and organizations who have expressed the desire to participate in the particular experiment in question.

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. Additionally it seems that there is no mention of other incompatibilities of senderid-core-00, including to STANDARD specification RFC2822 (see
http://www.imc.org/ietf-mxcomp/mail-archive/msg04751.html and
http://www.imc.org/ietf-mxcomp/mail-archive/msg04740.html and finally by
RFC2822 author - http://www.imc.org/ietf-mxcomp/mail-archive/msg04972.html)
which should have been of even greater importance. As such considering these two items, it seems the focus of IESG should be on making sure that
its senderid-core-00 draft that does not propose incompatible experiment
rather then trying to modify spf-classic-00 draft which on its own does
not have any problems like that.

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 hope SPF Council members either individually or together will promptly
make these issues known to Ted Hardie and resolve his misunderstanding of
the SPF community intentions.


P.S. I reserve the right to repost this message to general ietf mail list
if communication between SPF Council and IESG does not resolve the issues
within next few weeks to the satisfaction of others in SPF (i.e. if IESG does not promise that it will not make any changes to spf-classic-00 draft without agreement for it from both draft authors or from spf council).

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net