Subject: [ietf-dkim] LAST CALL ISSUE: Section 2.3 Evaluation Layer introduction

From: Hector Santos <[email-masked]>
Date: Tue, 12 Apr 2011 19:34:46 -0400

Fundamentally, we tried to make DKIM-BASE independent of specific 
implementation evaluation methods starting by pulling semantics 
regarding policy.

However, an evaluation layer for trust was reintroduced in section 2.3.

2.3.  Identity

    A person, role, or organization.  In the context of DKIM, examples
    include the author, the author's organization, an ISP along the
    handling path, an independent trust assessment service, and a mailing
    list operator.

While I personally thing this is good to help complete the mail system 
DKIM integration picture, I also think it better to keep it open-ended 
by excluding this layer semantic, change the text to signer domain or 
make it complete by including identity text regarding Policy Assessment.

Overall, the question is what is the technical identity that reflects:

    ISP
    Independent Trust Assessment Service
    Mailing List

We know signer domain is desired for the trust assessment, and we can 
presume something like the list-id for mailing list can be be used but 
what will reflect the ISP and why also have ESP or just mail host?

But to keep this simple, while I believe it the trust layer 
introduction is not consistent in 2.3, I would like to see that we 
also add Policy Assessment semantics to this text.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Apr 2011 20:37:14 -0400

>     handling path, an independent trust assessment service, and a mailing

Per Murray request to suggest changes for posted issues, in lieu of 
removing the trust assessment layer semantic, a more consistent text 
that helps promote implementation synergism for wider deployment 
scenarios might be:

   2.3.  Identity

   A person, role, or organization.  In the context of DKIM, examples
   include the author, the author's organization, an author
   authorized signer or independent trusted signer domain
   along the handling path.

If considered, that would be enough for me to give the RFC4871bis last 
call a "ready to go" endorsement

-- 
HLS