Reuse of TXT : draft-ymbk-dns-choices-00.txt

I think it is important to have the working group consider the topic of 
re-using TXT records or using a new record type.  It is important for 
the working group to come to a conclusion on this topic before 
developing a syntax, as this may have specific implications on that 
syntax.
As input to the discussion, I am working on a document regarding adding 
data to DNS for new applications, and the current version can be found 
in draft-ymbk-dns-choices-00.txt which just was made available. Note 
that it is a -00 version of the document, but I thought it important to 
make it available now, as MARID needs to discuss the DNS RR type sooner 
rather than later. Yes, it is discussed in the IAB to potentially 
become an IAB statement, but as it is now, it is an individual 
submission.

Some MARID specific points to ponder:

With the hope being that MARID is a powerful weapon to be used to fend 
off spam, it is only a logical conclusion that spammers will resort to 
attacks on the DNS given their past redoubling of efforts to defeat 
anti-spam measures.  Therefore, deployment a MARID record must also 
consider the near-future deployment of DNSSEC.  Additionally, the 
development and deployment of DNS is not standing still.  It is 
reasonable to expect new releases of DNS software in the normal course 
of Internet evolution for such purposes as maintenance releases, bug 
fixes, security patches and new features such as the upcoming SSHFP and 
IPSECKEY records.
Given the size constraints on DNS records, it be may desirable to avoid 
more verbose syntaxes.  DNS is capable of representing 8-bit values in 
RDATA.  Therefore, it is possible to define a new record type with a 
more bandwidth efficient binary format or perhaps a tokenized or 
compressed form of a more verbose text syntax.  However, it should be 
noted that new DNS record types cannot take advantage of the existing 
DNS label compression.
Consideration should also be given for the need of wizards and other 
administrative assistance software in the face of complex text syntaxes 
(one example of this type of software may be found at 
http://spf.pobox.com/wizard.html).  The familiarity of these syntaxes 
by protocol developers should not be conflated for ease-of-use by 
network administrators lacking the luxury to understand intimate 
details of all aspects of systems they administer.  It is not 
unreasonable to conclude the necessity of wizards for mass acceptance 
of a MARID solution.  Taken one step further, it is just as easy for a 
wizard to construct a binary form as it is to construct a text syntax.
Regarding fear for new RR Types, interoperability testing of RFC 3597 
has just started, and you should stay in touch with the project listed 
at http://www.rfc.se/interop3597/, or even better, support and help.
      Patrik Fältström