Hi All,
Sorry about the delay with this, Barry and I had problems syncing
up over the holiday and have only now gotten this done.
The attached contains our view on the current list of SSP issues [1]
except for those opened in the last week or so. (Sorry the
formatting's a bit crappy.)
Can you check that these seem ok, or comment where they don't?
Please comment in the original thread so we can more easily
track things.
The editors of the I-D have a new revision almost ready to post,
so what we'd suggest is that we let them watch the list traffic
over the next week or so, then have them post an I-D reflecting
where we are with these issues, and then we can schedule doing
the jabber/concall thing to progress if necesary.
Regards,
Stephen.
[1]
https://rt.psg.com/Search/Results.html?Order=ASC&Query=Queue%20%3D%20'dkim'%20AND%20(Status%20%3D%20'open'%20OR%20Status%20%3D%20'new')&Rows=50&OrderBy=id&Format=
1382 (SSP) New resource record type new dkim Nobody 0
ietf-dkim(_at_)kitterman(_dot_)com 1 years ago 1 years ago 0
Proposal: ACCEPT(CLOSE), we seem to have WG consensus to use
TXT only, and that's in the current I-D
1399 clarify i= vs. SSP open dkim Nobody 0
mike(_at_)mtcc(_dot_)com 1 years ago 1 years ago 0
Proposal: OPEN, Maybe merge this with a newer one? Probably 1519
1402 Applicability of SSP to subdomains open dkim Nobody 0
fenton(_at_)cisco(_dot_)com 1 years ago 6 days ago 0
Proposal: CLOSE, process this in the more recent issue #1534
1512 ssp should not link "all" and third parties new dkim Nobody
0 mike(_at_)mtcc(_dot_)com 6 weeks ago 6 weeks ago 0
Proposal: OPEN, we seemed to reach consensus in this thread [1]
but I'm not clear what the resulting
change to the spec should be. presumably we can close this with
the next rev
[1] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008275.html
1513 the new handling tag new dkim Nobody 0
mike(_at_)mtcc(_dot_)com 6 weeks ago 6 weeks ago 0
Proposal: OPEN, needs more discussion
1519 SSP-01 Unnecessary constraint on i= when asserting "strict" open
dkim Nobody 0 dotis(_at_)mail-abuse(_dot_)org 13 days ago
13 days ago 0
Proposal: OPEN, needs more discussion, Doug proposed some
changes that Jim didn't like in this thread [2]
[2] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008248.html
1520 limiting SSP to statements that inform recipient about (potential)
signer actions new dkim Nobody 0 dhc(_at_)dcrocker(_dot_)net 9
days ago 8 days ago 0
Proposal: OPEN, we seem to have about 3 for this and about 6
against, but more opinions are needed, thread is [3]
[3] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008423.html
1521 Limit the application of SSP to unsigned messages new dkim
Nobody 0 dhc(_at_)dcrocker(_dot_)net 9 days ago 9 days ago 0
Proposal: REJECT, but some wording changes may be needed for
the next rev, thread is [4] I mainly saw opposition to the change suggested
in the issue, and little support, but some text clarifying
changes were suggested (e.g. [5]).
[4] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008424.html
[5] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008467.html
1522 Discussion of query traffic overhead new dkim Nobody 0
dhc(_at_)dcrocker(_dot_)net 9 days ago 9 days ago 0
Proposal: ACCEPT(CHECK), thread is [6], 2 opinions that there's
no problem, but some concern that the text
in the draft is incomplete wrt DNS lookups; should hopefully be
closed with next rev, check again then
[6] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008425.html
1523 Service Model summary new dkim Nobody 0
dhc(_at_)dcrocker(_dot_)net 9 days ago 9 days ago 0
Proposal: OPEN, thread is [7], no real discussion but hopefully
clarified by next rev, check again then
[7] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008426.html
1524 Signature semantics new dkim Nobody 0
dhc(_at_)dcrocker(_dot_)net 9 days ago 9 days ago 0
Proposal: OPEN, thread is [8], lots of discussion, no clear
consensus, one possible actionable change [9]
[8] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008427.html
[9] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008603.html
1525 Restriction to posting by first Author breaks email semantics new
dkim Nobody 0 dhc(_at_)dcrocker(_dot_)net 9 days ago 9 days
ago 0
Proposal: REJECT, thread is [10], mailing list discussion has
not unearthed support for a change.
[10] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008428.html
[11] http://tools.ietf.org/html/rfc5016#section-5.3
1526 SSP applies only to receive-side filtering engine and not end-users
new dkim Nobody 0 dhc(_at_)dcrocker(_dot_)net 9 days ago
9 days ago 0
Proposal: ACCEPT(CHECK), thread is [12] there seemed to be
consensus to make such changes, but no specific changes
have been proposed, so we'll have to check the next rev
[12] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008429.html
1527 SSP threats analysis needed new dkim Nobody 0
dhc(_at_)dcrocker(_dot_)net 9 days ago 9 days ago 0
Proposal: ACCEPT(CHECK), threads [13,14,15] general agreement
that this is good, but no concrete text proposals
for the I-D, nor has anyone stepped up to do concerted
additional work on this, nor have any specific
new threats been discussed on the list, so we suggest letting
the editors work on the security considerations
section in the next I-D, and then people can raise any specific
threats they see as not being covered
in that rev (please send suggested text to the editors if
you've got any)
[13] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008430.html
[14] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008701.html
[15] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008512.html
1528 false negatives and false positives new dkim Nobody 0
dhc(_at_)dcrocker(_dot_)net 9 days ago 9 days ago 0
Proposal: OPEN, thread is [16] little discussion, might be a
subset of issue 1527
[16] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008431.html
1529 Change "originator" to "author" new dkim Nobody 0
dhc(_at_)dcrocker(_dot_)net 9 days ago 9 days ago 0
Proposal: ACCEPT(CHECK), thread is [17] we seem to have
consensus on this one
[17] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008432.html
1530 replace use of term "suspicious" new dkim Nobody 0
dhc(_at_)dcrocker(_dot_)net 9 days ago 9 days ago 0
Proposal: ACCEPT(CHECK), thread is [18] we seem to have
conesnsus for a change, suggest letting the
editors pick something and then go with that or raise a new
issue
[18] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008433.html
1531 "does not exist" new dkim Nobody 0
dhc(_at_)dcrocker(_dot_)net 9 days ago 9 days ago 0
Proposal: ACCEPT(CHECK), thread is [19], seems to call for some
clarifying text and/or a better
definition, suggest letting editor work that and check next rev
[19] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008434.html
1532 revise list labeling new dkim Nobody 0
dhc(_at_)dcrocker(_dot_)net 9 days ago 9 days ago 0
Proposal: ACCEPT(CHECK), thread is [20], editor says he'll work
it for next rev
[20] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008435.html
1533 strict vs. integrated new dkim Nobody 0
dhc(_at_)dcrocker(_dot_)net 9 days ago 9 days ago 0
Proposal: OPEN, thread is [21] little discussion & no clear
conclusion to act on so far
[21] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008435.html
1534 Applying SSP to sub-domains does not work new dkim Nobody
0 dhc(_at_)dcrocker(_dot_)net 9 days ago 9 days ago 0
Proposal: OPEN, thread is [22] needs more discussion as to
whether current I-D represents
consensus or not (Note: this replaces issue 1402)
[22] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008437.html
1535 Simplify SSP decision tree new dkim Nobody 0
dhc(_at_)dcrocker(_dot_)net 9 days ago 9 days ago 0
Proposal: ACCEPT(CHECK), thread is [23], some discussion but
mostly about issue 1540 on t=testing,
suggest letting editor make that and other changes and then see
if this can be closed or if
there's still an opinion that the state machine is over complex
[23] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008670.html
1536 definition of action terms new dkim Nobody 0
dhc(_at_)dcrocker(_dot_)net 9 days ago 9 days ago 0
Proposal: ACCEPT(CHECK), thread is [24], little discussion but
the terms aren't currently
defined, so suggest letting editors add definitions and
checking those in next rev (and
do provide editors with input please)
[24] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008439.html
1537 Reputation is out of scope or define it new dkim Nobody 0
hsantos(_at_)santronics(_dot_)com 8 days ago 8 days ago 0
Proposal: REJECT, thread is [25] Eliot's response [26] seems to
indicate that the I-D already
satisfies the request in the isseu
[25] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008472.html
[26] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008660.html
1538 review and repair of normative vocabulary usage new dkim Nobody
0 dhc(_at_)dcrocker(_dot_)net 8 days ago 8 days ago
Proposal: ACCEPT(CHECK), thread is [27], no discussion, let's
do that review on the next I-D
[27] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008491.html
1540 deprecate t=testing
Proposal: ACCEPT(CHECK), thread is [28] seems to have consensus
[28] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008594.html
XXX1 remove [FWS]
Proposal: OPEN, no discussion, thread is [29]
[29] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008477.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html