Mike,
Those were the questions for which Jim was looking for guidance
in the production of draft-ietf-skim-ssp-00. As I said, I don't
think we're setting anything in stone at this point (e.g. responses
so far all picked the "do a TXT RR" option - regardless of what
you think of that technically, it may just not fly in the IETF,
but even so, I'd have no problem if -00 says to use TXT.)
I don't think we want to have a number of I-Ds on the table,
but rather one WG draft, that will evolve over the next few
months. We did that already and make little progress with
four different proposals. Yes, we now have the requirements
agreed, but I think we've seen this week on the list that
people will stray from those if given the chance;-) I'd
much prefer we concentrate on one I-D from now on - its
basically the only way we can have a chance to meet our
charter goal of WGLC on SSP by November.
So, I'd ask you to suspend your disbelief until Jim's
managed to get that -00 out.
Then, if you still feel there's a need for more I-Ds, I guess
you can write draft-thomas-dkim-ssp-00 if you think that's a
better approach than working to get a draft-ietf-dkim-ssp-01
that you think works,
Sound reasonable?
S.
Michael Thomas wrote:
Stephen --
This list of yes/no's is not helpful is it quite possible to permute
these independent variables and arrive with something that cannot
work. What we *really* *really* need is an *exact* proposal that
claims to solve this problem so that we can evaluate the alternatives
against the Requirements, as well as their other merits. Design by
hum here is doomed to fail.
My suggestion: require those *fleshed out* proposals to be submitted as
ID's so that we can have time to read them, get clarification and
consider the tradoffs. Yes, an ID not just one-off wg mailing list
handwaving messages.
Mike
Stephen Farrell wrote:
Let's try get back to Jim's issues. What we need to do is help
get ssp-00 out so that we have an I-D as a basis for discussion.
What I'd like to do is get a sense of what we'd like to see
in draft-ietf-dkim-ssp-00, in terms of the options that Jim
(as editor) has chosen. (So please don't start with your
favourite alternative approach, at least not in this thread.)
At this stage its perfectly fine to want to see how something
pans out, and ask for it to be included now, but later ask for it
to be changed/removed - this isn't WGLC, we're just helping the
authors decide what to include in the -00 version.
I think that Jim is planning to edit -00 in the coming days
so if you say nothing, he'll just pick what he wants to include.
If you say too much, he'll also just pick what he wants to
include. If its inconclusive, he'll also just pick what he
wants to include.
To that end, please respond, by Monday, to this with +1/-1's as
described below (the description of the issues is from Jim's
original mail [1]):
(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
(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
(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
Stephen.
[1] http://mipassoc.org/pipermail/ietf-dkim/2007q2/007537.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html