(1) Use of XPTR records for SSP. The idea here is to create a more
general policy mechanism that can be used by WS-* and such. There
were about 20 messages discussing this from 5 people. I'm not
reading a clear consensus on this.
Issue#1: +1 - include use of XPTR as part of ssp-00
Issue#1: -1 - exclude use of XPTR from ssp-00
0 (if the decision is to go TXT-only, then -1, else neutral).
(2) SSP record type (TXT vs. something new). Only 4 messages in
discussion, mostly saying "if you support TXT, don't bother with
anything else." Again, no clear consensus.
Issue#2: +1 - Define how to use a TXT RR for SSP policies (with
or
without something else)
Issue#2: -1 - Don't use TXT at all, only use new RRs for SSP
+1 (with a new RR that is searched ahead of TXT).
(3) Upward query vs. wildcard publication. 27 messages in
discussion from 15 people. Most of the discussion was a rehash of
the idea of associating semantics with DNS zone-cuts, which we had
already discussed and rejected. I have also been trying to get an
opinion from DNSOP on the idea of a one-level upward search (which
I think solves 90% of the problem), but haven't gotten any response.
Issue#3: +1 - Define an upward query based approach to finding
SSP
statements
Issue#3: -1 - Define a wildcard based approach to finding SSP
statemetns
This isn't independent of Issue#2. If we use existing RR types (TXT,
no XPTR) then we are pretty much constrained to +1. If we use a new
RR type of some sort, then I prefer -1.
My thought would be to search for a new record type if you can (i.e.,
if your resolver supports the new type, be it XPTR or SSP).
Wildcards would be used to catch these. If you can't, or if there is
no such record, then fall back to TXT, at which point you have to
search up the tree. The intent would be to (someday) deprecate the
TXT search, if possible, which it probably isn't, but it does give
you a way to do the lookups more efficiently (wildcarding) if both
sides are willing to play. My hunch is that most of the big players
will.
eric
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html