Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10

2011-05-11 Thread Hector Santos
Barry Leiba wrote:
> The DKIM Working Group requests the publication of
> draft-ietf-dkim-mailinglists-10 as a BCP. Alternatively, this document
> might be suitable for Pete's "Applicability Statement" experiment, at
> the Proposed Standard level.
> 
> Please see the attached PROTO writeup.
> 
> Barry, DKIM working group chair

>  (1.b) Has the document had adequate review both from key WG members 
>and from key non-WG members? Does the Document Shepherd have 
>any concerns about the depth or breadth of the reviews that 
>have been performed?  
>
> The document has adequate review, and I have no concerns about the 
> level of review.

>  (1.e) How solid is the WG consensus behind this document? Does it 
>represent the strong concurrence of a few individuals, with 
>others being silent, or does the WG as a whole understand and 
>agree with it?   

> There is consensus of the working group, as a whole, behind it.  A
> minority of participants feel that the advice given in the last paragraph
> of section 1 is all that makes sense, and that the rest of the document
> isn't needed (see "Working Group Summary" later in this writeup).  Those
> participants are willing to accept this document, nonetheless, seeing
> no harm in it.

I was the MLM I-D non-acknowledged person who highlighted the 
interoperability problem with MLM and DKIM (RFC4871) and ADSP (RFC5617 
plus all other related document.  The Author Domain awareness 
solutions described were my inputs ad outlined in the expired 2006 
DSAP I-D.

As described in MLM I-D section 1.1:

The DKIM signing specification deliberately rejects the notion of
tying the signing domain (the "d=" tag in a DKIM signature) to any
other identifier within a message; any ADMD that handles a message
could sign it, regardless of its origin or author domain.  In
particular, DKIM does not define any meaning to the occurrence of a
match between the content of a "d=" tag and the value of, for
example, a domain name in the RFC5322.From field, nor is there any
obvious degraded value to a signature where they do not match.  Since
any DKIM signature is merely an assertion of "some" responsibility by
an ADMD, a DKIM signature added by an MLM has no more, nor less,
meaning than a signature with any other "d=" value.

This must be a PROBLEM statement because the MLM I-D offers solutions 
to deal with protocol definable "obvious" associations declared by the 
author domain.

If there is a consensus to accept this MLM I-D document to address 
concerns with the MLM interoperability problems, then it conflicts 
with the stated non-consensus chair conclusion related to Ticket #25 
for RFC4871bis to close the issue.

-- 
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


Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10

2011-05-11 Thread Barry Leiba
I'm sorry, Hector: I can't understand what you're saying in this
message, nor what you want done.

Barry, as chair

On Wed, May 11, 2011 at 03:35, Hector Santos  wrote:
>> There is consensus of the working group, as a whole, behind it.  A
>> minority of participants feel that the advice given in the last paragraph
>> of section 1 is all that makes sense, and that the rest of the document
>> isn't needed (see "Working Group Summary" later in this writeup).  Those
>> participants are willing to accept this document, nonetheless, seeing
>> no harm in it.
>
> I was the MLM I-D non-acknowledged person who highlighted the
> interoperability problem with MLM and DKIM (RFC4871) and ADSP (RFC5617 plus
> all other related document.  The Author Domain awareness solutions described
> were my inputs ad outlined in the expired 2006 DSAP I-D.
>
> As described in MLM I-D section 1.1:
>
>   The DKIM signing specification deliberately rejects the notion of
>   tying the signing domain (the "d=" tag in a DKIM signature) to any
>   other identifier within a message; any ADMD that handles a message
>   could sign it, regardless of its origin or author domain.  In
>   particular, DKIM does not define any meaning to the occurrence of a
>   match between the content of a "d=" tag and the value of, for
>   example, a domain name in the RFC5322.From field, nor is there any
>   obvious degraded value to a signature where they do not match.  Since
>   any DKIM signature is merely an assertion of "some" responsibility by
>   an ADMD, a DKIM signature added by an MLM has no more, nor less,
>   meaning than a signature with any other "d=" value.
>
> This must be a PROBLEM statement because the MLM I-D offers solutions to
> deal with protocol definable "obvious" associations declared by the author
> domain.
>
> If there is a consensus to accept this MLM I-D document to address concerns
> with the MLM interoperability problems, then it conflicts with the stated
> non-consensus chair conclusion related to Ticket #25 for RFC4871bis to close
> the issue.
>
> --
> 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


Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10

2011-05-11 Thread Dave CROCKER
Barry,

On 5/10/2011 6:45 PM, Barry Leiba wrote:
> The DKIM Working Group requests the publication of
> draft-ietf-dkim-mailinglists-10 as a BCP. Alternatively, this document
> might be suitable for Pete's "Applicability Statement" experiment, at
> the Proposed Standard level.


Why are you suggesting that we offer to participate in an experiment?

1. The offer primarily serves to suggest that the document has questionable 
purpose or clarity.

2. The 'experiment' is a glimmer in Pete's idea, not a well-formulated plan 
with 
support that is gaining momentum.  All that might get better, by what is the 
benefit of introducing a possible linkage?

3.  As negotiating model's go, it is counter-productive to open with a 
fall-back 
offer.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10

2011-05-11 Thread Barry Leiba
> 1. The offer primarily serves to suggest that the document has questionable
> purpose or clarity.

Offering to make the document a Proposed Standard, on the standards
track, suggests that it's questionable?  I fail to see that.

> 3.  As negotiating model's go, it is counter-productive to open with a
> fall-back offer.

There is no sense in which this is a "fall-back".  I see it as a
*better* mechanism for this document than BCP, if the IESG decides
that it agrees.  The "experiment" is seeing if the IESG agrees, and
the fall-back is BCP.

Barry

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


Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10

2011-05-11 Thread Dave CROCKER


On 5/11/2011 8:22 AM, Barry Leiba wrote:
>> 3.  As negotiating model's go, it is counter-productive to open with a
>> fall-back offer.

Offering to participate in an unformulated experiment that has no schedule is a 
fallback, yes.


> There is no sense in which this is a "fall-back".  I see it as a
> *better* mechanism for this document than BCP, if the IESG decides
> that it agrees.  The "experiment" is seeing if the IESG agrees, and
> the fall-back is BCP.

Perhaps I missed the working group discussion that agreed to this approach?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10

2011-05-11 Thread Barry Leiba
> Perhaps I missed the working group discussion that agreed to this approach?

This is a valid point.  Sean, please consider that the working group
did not discuss the possibility of changing the status from BCP to
Proposed Standard.  You might remove that from the writeup.

Barry, as chair
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10

2011-05-11 Thread John R. Levine
> This is a valid point.  Sean, please consider that the working group
> did not discuss the possibility of changing the status from BCP to
> Proposed Standard.  You might remove that from the writeup.

I suspect you would find signficant objection to making it a PS.

Considering how little of the advice is based on actual practice, even BCP 
is a stretch.

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10

2011-05-11 Thread Hector Santos
John R. Levine wrote:
>> This is a valid point.  Sean, please consider that the working group
>> did not discuss the possibility of changing the status from BCP to
>> Proposed Standard.  You might remove that from the writeup.
> 
> I suspect you would find signficant objection to making it a PS.
> 
> Considering how little of the advice is based on actual practice, even BCP 
> is a stretch.

G-d! and I was deathly afraid to comment on the same thing! So I'm 
happy you said it!

-- 
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


Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10

2011-05-11 Thread Murray S. Kucherawy
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of John R. Levine
> Sent: Wednesday, May 11, 2011 8:47 AM
> To: Barry Leiba
> Cc: DKIM Mailing List
> Subject: Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10
> 
> > This is a valid point.  Sean, please consider that the working group
> > did not discuss the possibility of changing the status from BCP to
> > Proposed Standard.  You might remove that from the writeup.
> 
> I suspect you would find signficant objection to making it a PS.

Probably not if it's made into an Applicability Statement:

http://tools.ietf.org/html/rfc2026#section-3.2


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


Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10

2011-05-11 Thread Dave CROCKER


On 5/11/2011 10:17 AM, Murray S. Kucherawy wrote:
>> I suspect you would find signficant objection to making it a PS.
>
> Probably not if it's made into an Applicability Statement:
>
> http://tools.ietf.org/html/rfc2026#section-3.2


That's simultaneously a reasonable and a terrible idea.

The construct is currently unused and is also currently under discussion.

IMO, we should stay away from nascent experiments about fuzzy topics with a 
poor 
track-record.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10

2011-05-11 Thread Pete Resnick
On 5/10/11 8:45 PM, Barry Leiba wrote:
> ...this document might be suitable for Pete's "Applicability Statement" 
> experiment, at
> the Proposed Standard level.
>

Leaving aside the question of whether or not this is a good idea...

I am of course pleased to see that Barry has interest in my experiment 
(so much so that he posted about it over 15 hours before I posted my 
announcement of it :-) ), but:

1. If you are curious, you can read about the experiment here: 


2. This is an apps area (and, more precisely, a "Pete's working groups 
in the apps area") experiment, and though I'd be perfectly happy if 
other WGs and ADs participated, that's between the WGs, the chairs, and 
the ADs. So this one is a decision that DKIM, the DKIM chairs, and Sean 
get to collectively make.

3. One can always publish something as BCP now, and if in the future you 
find that my experiment was so wildly successful that you wish to have a 
document as an AS, you can always re-publish, obsoleting the BCP.

Hope that helps.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

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


Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10

2011-05-11 Thread Sean Turner
On 5/11/11 1:32 PM, Dave CROCKER wrote:
>
>
> On 5/11/2011 10:17 AM, Murray S. Kucherawy wrote:
>>> I suspect you would find signficant objection to making it a PS.
>>
>> Probably not if it's made into an Applicability Statement:
>>
>> http://tools.ietf.org/html/rfc2026#section-3.2
>
>
> That's simultaneously a reasonable and a terrible idea.
>
> The construct is currently unused and is also currently under discussion.
>
> IMO, we should stay away from nascent experiments about fuzzy topics with a 
> poor
> track-record.

I'm going to pass on the experiment.  I want to see if the guinea pig 
survives first.

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