Hi Hector,
At 07:16 20-08-2013, Hector Santos wrote:
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.
This would be a process issue then as the SPFBIS Chairs determination
was made on the basic of the text from the SPFBIS Charter which was
cited. A person can raise an objection (I am okay with that as
that's part of the work) with substantive comments to support the objection.
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.
My reading of the SPFBIS Charter is that the working group was not
tasked to work on the future of DNS servers. That does not mean that
arguments about the future of DNS servers are not relevant.
There are several questions:
(a) Was there an error in RFC 4408?
(b) What was the error in RFC 4408?
(c) Why was there an error in RFC 4408?
(d) What should be done about the error?
There isn't anything that can be done about question (c) except not
to repeat the same mistake.
Is there disagreement on the answers to questions (a) and (b)?
Regards,
S. Moonesamy (as document shepherd)