> -----Original Message-----
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Hector Santos
> Sent: Wednesday, May 04, 2011 4:22 PM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
> 
> > You want AUID and RFC5322.From added to the Output Requirements
> > section explicitly.  At least two other participants disagree on
> > either technical or procedural grounds.
> 
> 1) I have not seen any no arguments based on technical merits, or one
> that didn't have an substantial proof.  Purely procedural and even SM
> showed your opinion on procedural (for BIS work) was not quite IETF
> correct.

You're not reading our replies then.  So here we go again, once more for the 
record, one of each:

Technical: The AUID is an unvetted value.  The local-part and the subdomain 
could be garbage.  It's inappropriate for a security protocol to return a 
possibly false value in the context of saying something was cryptographically 
validated.  Moreover, the suggestion conflates protocol and implementation; you 
can already pass the AUID, the From: field, or any other value you want to an 
adjacent layer or module without requiring a change to the current wording of 
3.9.  The fact that some adjacent modules want or need it is not proscribed by 
the current wording either, so the proposed change is actually unnecessary.

Procedural: Working group consensus to date has been to list only SDID as the 
required output, along with a status (see RFC5672, and RFC4871bis WGLC 
traffic).  Adding a value to the list of outputs is in contradiction to the 
Draft Standards advancement process (see BCP9, Section 4.1.2).  Only removing 
things is allowed.  SM didn't correct my interpretation of BCP9, but rather 
highlighted another aspect of it.  What he said and what I said are both 
correct.

> 2) There are at least four others (including myself) who agree with
> the ODID proposal of both variable or one of them.

I've only seen one other that supports the RFC5322.From as being a mandatory 
output.  So let's tackle that now too, for the record:

Technical: The RFC5322.From is an unvetted value.  The entire field could be 
garbage.  It's inappropriate; see above, same reasons.

Procedural: Adding a value, see above, same reasons.

> > So what's the compromise?
> 
> Your ball.  You are the editor of the documents. Its up to you to
> reduce the conflicts with proposed compromising text.  Murray, I am
> not your problem as much you believe, insist it is.

I encourage you to read The Tao of IETF, http://www.ietf.org/tao.html, 
especially Section 5.3 which explains the role of the document editor.  
Contrary to what you seem to believe, it is not our job to find a way to slip 
your suggestion in to the document just because it is repeated often.  Rather, 
a change to a standards track document, which RFC4871 and RFC5672 are, requires 
working group consensus and then similarly consensus up the chain of approval.  
It is not up to us to encourage consensus or compromise for submitted ideas; 
it's up to the people making the submissions.  That's you here.  If you want 
the change, you do the legwork.

So far I don't see consensus that the RFC5322.From or AUID additions to 3.9 is 
an allowable change procedurally, or a supported one technically.  That's why 
it's not included.  You may of course appeal to the chair if you have different 
information than I do, but that's where it stands.


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

Reply via email to