Re: [ietf-dkim] Modified Introduction text for rfc4871-errata

Dave CROCKER wrote:

Jim Fenton wrote:

Can you clarify what IESG concern this is attempting to address? 

Frankly, for that level of question, I suggest you direct it to our area director.  That will be far more efficient than my attempting to channel him and the rest of the IESG.

OK.

Pasi:

Dave has proposed a change to the rfc4871-errata draft in response to a concern from the IESG.  Can you clarify what concern the IESG has this is attempting to address?  I'll repeat my original question below since you may have missed it.

-Jim

Jim Fenton wrote:

Can you clarify what IESG concern this is attempting to address?  I
looked at the IESG evaluation record for the draft
(https://datatracker.ietf.org/idtracker/ballot/3084/) and didn't see
anything that this change would address, except possibly Cullen's
comment that he asked three developers what changes to a 4871
implementation might be required and they told him "this document was
completely incomprehensible and they have no idea what needs to change."

I don't see this modification as addressing that comment.

-Jim

Dave CROCKER wrote:
  

Folks,

In reviewing the errata (Update) draft, the IESG expressed concern that a reader 
could miss that there is a potential for software changes due to the change in 
the specification.  Indeed, some IESG readers and others did believe there was 
no software change needed.

To clarify things, without producing text that makes integration into the base 
document a challenge later, a modification to the Introduction is proposed.  I'm 
circulating it to the mailing list to be sure that there are no land mines in 
its interpretations.

If the proposed changes causes you particular heartburn, please explain your 
concern in detail.

Thanks.

d/


Existing Introduction text:

  
    

   This currently leaves signers and assessors with the potential for
   having differing -- and therefore non-interoperable --
   interpretations of how DKIM operates.

   This update resolves this confusion.  It defines new labels for the
   two values, clarifies their nature, and specifies their relationship.

    
      

Proposed text:

       <t>This currently leaves signers and assessors with the potential for
         making different interpretations between the two identifiers and may
         lead to interoperability problems. A signer could intend one to be
         used for reputation, and have a non-reputation intent in setting the
         value in the other. However the assessor might choose the wrong value
         and produce an unintended (and inaccurate) reputation assessment.</t>

       <t>This update resolves that confusion.  It defines additional, semantic
         labels for the two values, clarifies their nature and specifies their
         relationship.  More specifically, it clarifies that the identifier
         intended for reputation lookups (such as white lists) by the
         assessor is the value of the "d=" tag. However, this does not
         prohibit message filtering engines from using the "i=" tag, or any
         other information in the message header, for filtering decisions. </t>

       <t>For signers and assessors that have been using the i= tag for
         reputation assessment a software change to using the d= tag is intended.
       </t>

  
    

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