Re: [spfbis] Last Call: <draft-ietf-spfbis-experiment-09.txt> (Resolution of The SPF and Sender ID Experiments) to Informational RFC

[S Moonesamy <[e-mail]>]

Hi Arthur,
At 11:56 04-06-2012, Arthur Thisell wrote:
>I have reviewed the last call draft and find it quite acceptable for 
>publication.

Thanks for the review.

>I realize I've been quite lax in following this WG lately and I 
>should posted comments earlier.  In hind sight, I doubt any comments 
>I would have made would have made any significant improvements to 
>the draft, it turned out just fine without me.
>
>That said, here are a few comments...
>
>1) It was never clear to me why the IESG declared these MARID drafts 
>as being experimental.   Besides the possible confusion between 
>interpreting records as both SPF and Sender ID, I was under the 
>impression that the IESG wasn't sure if these proposals would help 
>or hurt email in general, whether they would damage the function of 
>the DNS, and whether it was appropriate to let individual 
>submissions (the WG concluded without any approved IDs) to be other 
>than experimental or informational.  I'm not sure that there is much 
>point in speculating what the IESG thought, but this draft seems to 
>concentrate on only the SPF v Sender ID conflicts.

The second paragraph of Section 1 of draft-ietf-spfbis-experiment-09 
discusses about the publication status.

>2) I always thought that the type 99 transition plan was faulty, but 
>I could not think of anything better.   This draft glosses over some 
>key points about why it ended up with the transition plan that it did.
>
>* First, no one could come up with an example of a successful 
>transition where the original had significant deployment (like the 
>TXT records did) and the new version had no significant advantages 
>(the type 99 was exactly the same as TXT, other than theoretical 
>elegance.)  Even MX records still fall back to A records.
>
>* Jim and Harry from Microsoft expressed very strong objections to 
>any requirement that type 99 records MUST be checked.   Their 
>explanation was that apparently some MS applications used an API to 
>ask about DNS records, my impression was that this API worked 
>transparently on things like netware and their active directory and 
>such too.   No port 53 communication was done via this API, indeed, 
>port 53 was often explicitly blocked at the firewall so clients 
>couldn't even get around using this API if the wanted to.  This API 
>supported a very limited set of DNS records, TXT being one of them, 
>but had zero support for new/unknown record types.   Not only did 
>the then current version of that API have no way of querying type 99 
>records, the next version had been put into feature freeze, and the 
>version after that had no plans on adding such support.
>
>In short, if the RFCs required checking type 99 records, MS could 
>not produce implementations that could be standard compliant.  They 
>were willing to compromise on many things, but this wasn't one of them.
>
>On the other hand, people in the MARID WG objected to any 
>requirement to check TXT records, arguing that doing so would hinder 
>the transition to type 99 records since people could just publish 
>TXT records and know that they would always work.

According to the SPFBIS Charter the following is out-of-scope:

     "Revisiting past technical arguments where consensus was reached in
      the MARID working group, except where review is reasonably
      warranted based on operational experience."

The working group followed what was in the charter.

>So, the result was:
>
>* the RFC MUST NOT require checking type 99 records, or it would 
>lose support of MS.
>
>* the RFC MUST allow the checking of type 99 records, otherwise no 
>migration would be possible.
>
>* the RFC MUST NOT require checking of TXT records, or it would lose 
>support of IETF players and hinder migration.
>
>* the RFC MUST allow the checking of TXT records, otherwise you 
>would lose a large install base.
>
>I, and others, were quite aware at the time that the language put 
>into the RFC would make it so compliant implementations might not be 
>able to communicate with compliant publishers.  No one came forward 
>with better language.  I felt that as long as TXT could be used, 
>noting else was likely to matter.
>
>Hindsight is 20/20 and positions appear to have softened over the 
>years.  Things like DKIM managed to get by with much less 
>handwringing and I suspect if SPF was done today, known-bogus 
>language like this wouldn't have made it into the draft.


There were discussions about this issue on the WG mailing list and 
during last IETF meeting ( 
http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt ).

The matter was noted in the Write-up:

   The discussions about the RRTYPE 99 DNS Resource Record were controversial.
   The issue was resolved.

Regards,
S. Moonesamy (as document shepherd)