Hi Hector,
At 06:30 20-08-2013, Hector Santos wrote:
I have a few questions and points:
May I ask why was the above was not an area for clarification as
oppose as the presumed stated technical reason for removal?
The SPFBIS WG had a session at IETF 83. The minutes for that session
is at
http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt
Item C on the agenda is about "SPF RR Type and TXT RR (issue
#9)". Andrew Sullivan, as SPFBIS Chair, explained that:
'The were people on the mailing list in favor of using the TXT RR
appeared to be a modest majority and there were people who argued
for SPF RR Type on the grounds of DNS hygiene. The Chair explained
that it appears as an empirical matter, overwhelmingly, the TXT RR
is used but RRTYPE 99 does not qualify under the unused provision
of the SPFBIS charter.'
Pete Resnick, as Area Director, commented that:
'the deal with the IESG, as a general statement, the working can removed
what is unused and put in what is widely deployed. He pointed out that
saying that TXT RR is part of an experiment is contrary to the agreement
made with the IESG. His opinion is that either way, the proposal is stuck
with TXT RR and that it is not an issue. The only issue is whether the
proposal can remove the SPF RRTYPE as unused.'
On February 26, 2012, Barry Leiba, as a participant, posted a message
( http://www.ietf.org/mail-archive/web/spfbis/current/msg00654.html )
which I will quote:
"These two statements make a pretty compelling case that there is, indeed,
an error in RFC4408. There are, of course, multiple ways to resolve it,
and I have no immediate opinion on which is best."
My opinion, as one of the SPFBIS WG Chairs, was that there was an
error. As Barry Leiba mentioned, there were several possible ways to
fix that. The SPFBIS Chair stated at the meeting that:
"The conclusion reached by the Chair was that the document will say
SHOULD NOT publish RRTYPE 99 and MUST NOT query RRTYPE 99."
That statement was posted to the SPFBIS mailing list (
http://www.ietf.org/mail-archive/web/spfbis/current/msg01369.html
). Nobody disagreed.
There was adequate information for the expected and original optimal
migration plan but it could of been further codified and clarified.
It would of been on par with BIS level of work. Issue #9 should not
have been a reason for removal. I reported issue #25 [1] regarding
the complexity of the recommended parallel processing approach. I
believe most folks agreed the ideal and optimal migration approach was:
Query SPF type first,
Fallback to TXT secord.
It was common sense, at least to me.
Both Issue #9 and Issue #25 (see SPFBIS tracker) were
well-discussed. Was every technical point carefully considered? I
don't think so as it is possible that a technical point may have been
missed. There is an opportunity for anyone to comment during the
Last Call if the person believes that a technical point has been
missed or was not addressed appropriately by the working group. In
my opinion the SPFBIS WG carefully considered all the comments which
were made in reaching its decision.
Second, I was under the impression interop reports (RFC 6686) were
not making any conclusions or recommendations? Is that a correct
basic understanding of interop reports? They were observations,
collection of available data and while it might be eventually used
to rethink a protocol design, I don't think the above RFC 4408
statement is a serious "error" in the functional description to
justify removal. There are other parts of 4408 which helped clarify
the migration path.
From the Introduction Section of RFC 6686:
"In line with the IESG's request to evaluate after a period of time,
this document concludes the experiments by presenting evidence
regarding both deployment and comparative effect of the two
protocols. At the end, it presents conclusions based on the data
collected."
In my opinion RFC 6686 does make conclusions (see Section 6 of RFC
6686). There is some background information about the RRTYPE issue
in Appendix A.
But overall, a correction (not removal) would of suffice. It would
of been on par for BIS-like corrections and protocol updates.
Andrew Sullivan, as SPFBIS WG Chair, mentioned that "We have to do
_something_, though any action would introduce a backward
incompatibility (
http://www.ietf.org/mail-archive/web/spfbis/current/msg03595.html ).
Third, I believe removal required a more deeper IETF discussion
about the initial presumed engineering expectation that DNS servers
(all top DNS servers, including and especially Microsoft DNS
servers) would eventually directly support a new registered SPF type
or at the very least support RFC 3597 (Handling of Unknown DNS
Resource Record (RR) Type) [2].
There were comments about RFC 3567 during the working group
discussions (see
http://www.ietf.org/mail-archive/web/spfbis/current/msg00545.html
http://www.ietf.org/mail-archive/web/spfbis/current/msg00820.html ).
If this is no longer the expectation, then it would make sense to
remove the SPF type but also be aware that in general, this will
also nix (not help) any future idea for successfully adopting new RR types.
It would be added statement that TXT based applications are
acceptable. I think the DNS community continues to have a problem with this.
Noted.
SM, Pete, thank you for the opportunity to clarify my point. For the
record, there was no intent to imply it occurred but quite frankly
when it is repeatedly stated, this deeply divided issue has not be
resolved at any point, it does have an intimidation factor. As Mr.
Crocker stated, the burden is on the those who oppose the removal.
But my question was always why was the decision made to remove in
the first place done when in fact it was quite obvious it would not
have industry wide endorsement. The burden should of been to justify
removal. Now it has become difficult to effectively add it back.
This is why I posed the question in two forums to get community
input over the last few years. It was quite obvious to me that the
DNS community would be against this removal. So in this vain, it
was prematurely removed in the WG without early IETF/IESG/DNS
concerns adequately dealt with. Unfortunately, we were advise to
raise the issue again in LC, but by that point, all the IETF
procedural moves were made making it it a very high burden to add
something that should not been removed in the first place.
There are two SPFBIS WG Chairs. The way we work is: I read the
mailing list messages, the other Chair reads the mailing list
messages, each chair reaches his own conclusion and we discuss about
it. Once the Chairs agree a message is posted to the WG mailing
list. Let's assume that the Chairs did not carefully consider the
comments or their determination was incorrect. There is a Last Call
where the matter can be raised again. That is the advice that was
given. There is indeed a high burden as the person raising the issue
again will have to read the mailing list messages to determine
whether they have been carefully considered.
Regards,
S. Moonesamy (as document shepherd)