Hi Greg,
I agree. This is better. My suggestion was more about trying to get away
from having different lookup methods and complication the admin
documentation process and also help reduce some technical issues.
It might be a mute point though depending how the proposals "play out."
As an independent vendor, it is in my interest to support multiple proposals
to cover all bases at this early stage. So far, what I am seeing is some
are using SPF because it is easier to add, the wizard at the SPF web site
has helped. CEP with its XML format, is adding a level of complicity. Its
forcing the need to have a utility to help create the CEP XML record for the
admin which they can cut and paste into their DNS manager. Yet, we also see
some admins who are not supporting either at all and are sticking with
internal white/black list tables, DNSRBL methods and CBV. Go figure.
But in my personal view, one or the other (LMAP methods) will eventually
become the overwhelming most supported method. SPF is popular at the
moment, but CEP will overtake it rapidly for obvious reasons once MS makes
it official. In the long run, I don't think systems will be want to be
playing with multiple methods that basically do the same thing and for large
systems, they certainly do want to be doing multiple, redundant LMAP look
ups. But even if this is the case, I think it might help to have a single
lookup to get the domain policy or policies in one request.
Thanks for your comment.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Greg Connor" <gconnor(_at_)nekodojo(_dot_)org>
To: "IETF-MXCOMP" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Friday, April 16, 2004 5:09 PM
Subject: RE: TXT lookup domain - eliminating redundancy.
--"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> wrote:
I think that if we decide to reuse the TXT record, either as a final
or an interim solution then using _ep or _MARID as a key makes a
lot of sense.
I don't think it makes any sense to do this for a RR specific to MARID
Totally agree. The TXT and v=spf1 and _ep are ways of getting around the
"no RR is invented yet". If we define a new RR type, it makes most sense
to stick it on the domain itself and not confuse things further with added
_labels.
A version number is one way to allow for future extensibility in a way
that
doesn't confuse older clients, but there are other ways around this as
well.
In fact we could even punt and say the hex value of the MARID RR
# is 42, then an interim TXT record incarnation could be _42.example.com
Oooh, I like that idea. Anyway "interim" is the key word here.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>