Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

[Douglas Otis <[e-mail]>]

On Aug 25, 2005, at 11:26 AM, Ned Freed wrote:
>
>
>> A mail-sending domain indicates that it is participating by  
>> publishing
>> certain DNS RR's.
>> Crucially, a mail-sending domain cannot opt in to the SPF experiment
>> without also opting in to the senderid experiment.  This renders any
>> claimed results of either experiment suspect.
>>
>
> RIght again.
>
> In any case, I support this appeal to the extent that I believe the  
> conflicts
> need to be resolved prior to publication. I take no position on the  
> means
> by which the conflict is resolved as long as a resolution is reached.


As with any conflict, there are two parties involved.  In this case,  
the SPF group has essentially ignored potential conflicts by  
neglecting to include support for a subsequent version of the DNS  
record.  This newer record explicitly expresses the intended scope.   
At the MAAWG meeting in Dusseldorf, Julian suggested SPF developers  
would only consider use of the newer DNS record version provided  
Sender-ID abdicated use of the initial version of the record.  Sender- 
ID supports both versions.  An appeal was made for the SPF group to  
consider supporting the newer version of the record as a solution for  
avoiding this conflict.  This suggested use of the record is part of  
interim advice on the MAAWG website.  It would appear this appeal  
reflects a decisions to remain intransigent.

http://www.maawg.org/about/whitepapers/spf_sendID/

A condition that Sender-ID abdicate the use of the scope-less version  
of the record is puzzling, as once the newer record is also adopted  
by SPF, the claimed conflict is resolved.  Meng Wong, an author of  
both drafts, explained the conflict in his white paper by indicating  
the SPF draft was for historical purposes and suggested Sender-ID  
embraced both semantics.  Sender-ID's use of the initial version of  
the DNS record will create problems should the publisher of the  
record intend the semantics to exclude Sender-ID.  The methods  
suggested by the Sender-ID draft to circumvent their semantics could  
negatively impact the publisher.

This conflict is not accidental or without a simple solution, but  
rather based upon a desire to withdraw Sender-ID semantics in a manor  
that negatively impacts the Sender-ID effort.  I am _not_ a proponent  
of Sender-ID.  While the merging of semantics was initially  
considered acceptable by the MARID WG, the desire to now exclude the  
Sender-ID semantics is primarily due to subsequent licensing  
notifications.  At that time so long ago, the technical solution to  
allow the record publisher to formally indicate their desired  
semantics was to change the version of the record that provided the  
requisite scoping parameters.

Rather than adopting this solution, the SPF group insists anyone that  
published the initial version of this record only intended to support  
SPF and not Sender-ID.  This would be a difficult conclusion  
following any number of gatherings where email administrators have  
subsequently and repeatedly been provided information that indicated  
this initial record version supports both, and that the subsequent  
record versions can be used to isolate the scope of the record.

While this conflict should be resolved, without evidence that Sender- 
ID has fallen out of favor, which the stance by the SPF group  
prohibits, the obvious solution would likely be for the SPF group to  
finally adopt the newer record version.


-Doug

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf