ietf-mxcomp
[Top] [All Lists]

Re: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use

2004-06-11 11:58:50

On Thu, 2004-06-10 at 23:15, Michel Py wrote:
Douglas Otis wrote:
Looking to simplify an aspect of deployment must consider
the entire process. To premise a design based upon an
architecture where SMTP rarely enters without a bridging
component may place too much emphasis on this aspect over
perhaps more pressing matters having to do with the overall
integrity of the system.         

No argument here, has to see the big picture.

There is a problem in that the "core" proposal is adding
restrictions on a TXT record where few exist but stops short
of ensuring further changes occur as a result of a standards
process.

A very valid point indeed; however I think you do not put it in the
right context, and here's why:

In _appearance_, we are facing the following decision to make: pick one
out of the following three:

1. We do it quick and dirty with TXT.
2. We do it right and slow with a new RR type.
3. We say that we'll go with 1 as a temporary measure and with 2 in the
long run.

Two problems here:
a) All three have major shortcomings: 1 is dirty, 2 is too slow, and 3
is a bastard that leaves us with having to support both.
b) This "choice" is something we have only in _appearance_. In reality,
we don't have a choice and here's why:

- If this WG leans towards 1, there will be enough opposition about the
solution being dirty (and for good reasons) to stall the process and
never achieve the "quick" part of it.

- If this WG leans towards 2, a schism that will split the SPF community
will inevitably happen, and everyone loses. Not only the SPF spinoff
will deploy much sooner, likely making MARID irrelevant due to
time-to-market issues; but even worse the "old-new" SPF will still put
whatever they see fit in TXT outside of any IETF standard, which was
your fear in the first place.

- If this WG leans towards 3, it pleases no-one and goes nowhere. I have
seen enough "3 month temporary" solutions that are still in service 10
years later to believe in this one.


There is a way out of this, IMHO. This way is as follows:

I. We use the TXT RR for SPFID, because we need it now and not in 5
years.

II. At the same time, we obsolete the RFCs describing the
TXT RR and replace them with new text that says:

  i) The TXT RR is now reserved for SPFID and you can't put
     anything you want in it anymore; anything that would go
     into the TXT record needs to be cleared by MARID first.

  ii) We create a TXT1 RR that will fulfill the role
      previously assigned to the TXT RR.


Comments?

There is an alternative to a hostile take-over of the TXT record as I
mentioned.

Use a token such as "MARID-1" and follow this with a CRC-32c checksum
(good Hamming distance and code used in SCTP) of the entire record where
the checksum field is treated as zero.  Such as "MARID-1[FD034A45]..."
or perhaps "FD034A45_MARID-1...". See RFC3309 for an example of language
and code.  As it may be improbable a TXT record would start with the
token or checksum, but with the checksum it would take several lifetimes
of random text files before there should be a conflict.  The token would
also create a foundation for other future uses of the TXT record without
requiring a new record invented. This would be an alternative to the use
of the label to indicate revisions as would be a problem with SPF if its
label was replaced with an asterisk.

-Doug


Michel.