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. > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
