Re: [Gen-art] [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt

[Brian E Carpenter <[e-mail]>]

On 2012-06-07 08:58, Hector Santos wrote:
> S Moonesamy wrote:
> 
>>> Brian Carpenter wrote:
>>> Also, RFC4406 states that "Sending domains MAY publish either or both
>>> formats" (i.e. spf1 or spf2.0). That being so, I would ideally expect
>>> to see nine rows in the results table:
>>>
>>> SPF RR only, spf1 only
>>> SPF RR only, spf2.0 only
>>> SPF RR only, spf1 and spf2.0
>>> TXT RR only, spf1 only
>>> TXT RR only, spf2.0 only
>>> TXT RR only, spf1 and spf2.0
>>> SPF and TXT RRs, spf1 only
>>> SPF and TXT RRs, spf2.0 only
>>> SPF and TXT RRs, spf1 and spf2.0
>>
>> Pete suggests having two tables for each survey: (a) a comparison of
>> RRTYPEs, and (b) a comparison of SPF vs. SIDF independent of RRTYPE. 
>> Would that be sufficient?
> 
> I don't see where this is headed. The report was looking for something
> that was already there and know and I guess it trying to get a
> justification to eliminate something.
> 
> What are we looking for?

I am looking for clear presentation of the observed data, nothing more,
as I do whenever I read a data-based document. As my review stated,
I have no problem with the conclusions drawn in the draft.

   Brian

> 
>   Elimination of SPF RR lookups?
>   Elimination of SPF2.0 content in the SPF or TXT records?
> 
> I hate to revert back to the original design presumptions in MARID, but
> everyone was working on the basis that one day DNS servers, ALL OF THEM,
> CROSS THE OS BOARD, would inevitably be updated to support RFC3597
> Handling of Unknown DNS Resource Record (RR) Types.  But that has not
> been the case, MS DNS 5.0 was only updated to support SVR, DNSSEC. But
> not the passthru query recursive requirements necessary for RFC3597.
> 
> So supporting any unnamed RR type is simply not practical today.
> However, as predicted, the migration advice did materialize, abeit in
> short numbers.  So IMO, we need to make a decision if its still feasible
> to pursue unnamed RR type support.
> 
> Second and finally, the results of SPF2.0 record is irrelevant because
> this REPORT is not doing anything towards or does it have any business
> in eliminating or providing the "illusion" of eliminating Sender ID or
> SIDF (Sender ID Framework) which includes PRA and SUBMITTER protocol
> support.
> 
> This Report has failed to consider the original EXPERIMENTAL questions
> of the so call conflicts that were cited, ones I have failed to see
> since its inception in early 2000s.
> 
> Address the real technical issues so that deployments of many years can
> learn what do  do with the mix support of SPF vs SIDF and also TXT vs
> SPF RRs.  The data in this report has not provided any engineering
> insight whatsoever other than the fact that clients DO support both SIDF
> and SPF RRs.
>