ietf-dkim
[Top] [All Lists]

[ietf-dkim] SSP issues status

2008-01-10 11:30:42

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