Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Hector Santos <[e-mail]>]

On 8/20/2013 1:12 AM, S Moonesamy wrote:

> There is a message from the Responsible Area Director at
> http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html which
> might shine some light about that part of the charter.
>
> Both RR Type 16 and RR Type 99 are in use on the Internet.  Tony Hansen
> mentioned during the IETF 83 session that:
>
>    "when you write a protocol, there is definite harm if there is a
>     choice in what you publish and what you look for.  He is of
>     the view that there is a definite bug in RFC 4408."
>
> Fixing that bug falls within the scope of the SPFBIS charter, specifically:
>
>    "Changes to the SPF specification will be limited to the correction
>     of errors, removal of unused features, addition of any enhancements
>     that have already gained widespread support, and addition of
>     clarifying language. "


This doesn't seem to be correct. My apology if I don't follow or see the 
logic.   The only real issue as it was since day zero in MARID was the 
infrastructure support for recursive passthru queries which is what RFC 
3597 (Handling of Unknown DNS Resource Record (RR) Type).  Without this, 
which allows for servers to delay/plan direct new RR type support yet 
still not error out on an unnamed type, there COULD NOT be any 
reasonable expectation to even only suggest a dual query migration 
approach, either in serial or parallel. It is very important to consider 
the mindset when it was first considered and written for RFC 4408 
because to me, that is the mindset that has changed.

If we don't think the infrastructure, the DNS vendors primarily, will 
support RFC 3497, then it seems proper to me to finally forget the idea.

But if we still think its desirable and possible, then I would prefer to 
keep the protocol feature/option, corrected of course, and allow 
implementers the design choice to support it.

The way I see it, if more implementations did begin to add support of a 
clarified BIS specification, that doesn't mean they may enabled it 
(default ON) out of the box.  I would want to initially offer the lowest 
overheard operational setup out of the box.  It will still be a long 
term migration path, shorter if we can encourage the major DNS vendors 
to add at least RFC 3597 support.  Without, no new RR type will work 
across the board.


> The fourth paragraph (see quoted text) states that the conclusions from
> that where RFC 6866 were flawed and rushed.  The explanation given is
> because the working group declared failure too soon.  The SPFBIS WG
> discovered a bug during the review of the SPF specification.  One of the
> main considerations for the decision was to fix the bug.  The working
> group had to choose one RRTYPE as the conclusion was that it was the
> appropriate way to fix the bug and ensure interoperability.
>
> The comments posted up to now for the Last Call points to a disagreement
> about the choice of RRTYPE.

I hope I am reading this incorrectly.  It may be too procedural oriented 
to me at this point.

I would like to see a simple just distinctive consensus on what the 
entire IETF/DNS community believes is the future of DNS servers offering 
unnamed RR type processing because that is the main barrier for any kind 
success. We knew this as far back as MARID.  I don't quite understand 
why this key point seems to be left out, instead MARID was deemed off 
topic. That was an error because if there is no future in unnamed RR 
type support, then it really doesn't matter and the problem is solved. 
TXT only will be the only fast entry point for new DNS DOMAIN policy 
applications.

If the community still believes it possible, then clarifying and 
codifying the SPF/TYPE lookup procedure seems to me to be the only real 
correction to make here.

Thanks

--
HLS

[1] http://tools.ietf.org/html/rfc3597