At 08:05 19-08-2013, MÃns Nilsson wrote:
I strongly OPPOSE draft-ietf-spfbis-4408bis-19.txt being published as
RFC unless substantial parts are reworked.
* The charter disallows major protocol changes -- removing the SPF RR type
is a direct charter violation; since SPF is being used on the Internet.
* The overloading of the TXT record is a hack at best, aimed at
circumventing DNS management systems vendors that fail to ship
support. Breaking the DNS model with specific resource records is not
the way to get better application support. (besides, the major argument
at the time was "it's so hard and takes ages to get a RR type", which
isn't true anymore and also, the RRtype is allocated, what's the fuss? )
* The empirical data that was gathered and the conclusions from which
that where published as RFC 6686 are IMNSHO flawed and rushed in that they
set far too optimistic deadlines for adaptation before declaring failure.
The IESG should send draft-ietf-spfbis-4408bis-19 back to spfbis wg and tell
the wg that instead of deprecating SPF it should be algorithmically
preferred while maintaining support for TXT.
I read the SPFBIS charter (
https://datatracker.ietf.org/wg/spfbis/charter/ )
again. The charter violation the above may be referring might be about:
"Specifically out-of-scope for this working group:
* Removal of existing features that are in current use."
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. "
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.
Regards,
S. Moonesamy (as document shepherd)