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