In <200512091303.37502.julian@xxxxxxxxxx> Julian Mehnle <julian@xxxxxxxxxx> writes: > Pekka Savola wrote: >> >> Basically the IESG decided that accurate documentation of the running >> code is more important than documenting something that does not exist, >> and maybe never will exist. > > As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00 was > submitted for experimental status, there was no "running code" that > actually interpreted "v=spf1" as "spf2.0/mfrom,pra". So what running code > was being documented when draft-lyon-senderid-core-00 was submitted? Actually, I think the SenderID implementation from sendmail was interpreting "v=spf1" records using the PRA, but Julian's point is largely true: the vast majority of implementations that are abusing SPF version 1 records were released *SINCE* the first objections to the senderid drafts were raised. The number of SenderID implementations is still small. While I doubt that all implementations will be fixed, I think the IETF blessing the conflict will cause the number of implemenations to grow, rather than shrink. The IESG's first reaction to learning of the conflict between the use of SPF version 1 records by SenderID was to direct the RFC editor to remove the warning placed in the SPF I-D. The IESG did this *without* informing either of the draft authors about this technical change. It took a fair amount of discussion with the IESG to even allow this problem to be acknowledged. Now, obviously the IESG feels that they can freely make technical changes to drafts without the approval of draft authors. They also acknowledge that the abuse of SPF version 1 records by the SenderID spec causes problems. So, the question is: why didn't the IESG just change the SenderID drafts to something that doesn't conflict? -wayne _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf