Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Bill.Oxley]

Maybe I should read the other 22 posts before jumping in 
 
"RFC 4871 gives no precise definition of what an "assessor"
can use to make whatever decisions it wants to draw from
the message *and* the signature(s). "

correct and it should stay that way

Bill Oxley
Messaging Engineer
Cox Communications, Inc
404-847-6397

-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On 
Behalf Of Michael Thomas
Sent: Friday, March 20, 2009 9:39 PM
To: John R. Levine
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

John R. Levine wrote:
>>> We seem to have a fairly basic disconnect here.  As far as I'm
>>> concerned, an assessor has better things to worry about than the
>>> internal details of the signature. Trying to reverse engineer or guess
>>> what the signer had in mind would be a hopeless swamp even if it were
>>> desirable. ...
>
>> If assessors can't be bothered, then how will reputation systems know 
>> the
>> difference?
>
> Sorry, but I have no idea what the antecedent to this question is 
> supposed to be.  The difference between what and what?
>
>
>
You wrote:

> Sure, it's possible to put on a worthless signature that leaves out
> crucial headers, but signers who do so won't get a very good
> reputation so the problem should be self-limiting.  There's no
> existing installed base of inept signers we have to work around, and
> it would be a poor idea do anything that would allow crummy signatures
> to appear to work.

If assessors can't be bothered to assess the supposedly
"self-limiting" "implementation details", then reputation 
systems can not take them into account. By definition.

> Assessors know whether a message is signed, and if it has valid 
> signature(s), the domain(s) that signed them.  All that other stuff in the 
> signature is implementation details.

RFC 4871 gives no precise definition of what an "assessor"
can use to make whatever decisions it wants to draw from
the message *and* the signature(s). That you have a particular
use case in mind that doesn't care about "implementation
details" does not and should not imply that that is the only
valid use of DKIM information. That is why the errata is so
wrong headed.

Mike



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

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Dave CROCKER]

Jim Fenton wrote:
> 1. Introduction.  The introduction, particularly paragraphs 2 and 3, assert
> that the payload (the output of DKIM verification) is only a validated
> signing domain.  The output of DKIM verification is considerably more than
> that:

The Errata draft carefully documents the basis for what it asserts.

Where is the documentation that substantiates the claim of broader functionality
that you keep making?


> RFC 4871 somewhat narrowly defines a protocol between the signer and 
> verifier.

4871 defines a means of associating a domain name to a message and conveying it
with the message, so that the validator can trust its... validity.



> 6. SDID definition
> 
> I am confused by the definition of the SDID as opaque.  This makes it sound
> like it's a pseudonym for the actual signing domain.

I can't guess how you are deriving that interpretation, since the use of the
term, here, is identical with its typical use in the field, and that's not what
it means.


> 8. Identity Assessor
> 
> The term is imprecise:  it is not assessing an identity but a message.

Imprecise?What could be more precise than "name of the module that consumes
DKIM's primary payload"?

In any event, there is a difference between assessing the associated identity,
versus assessing a message.  The former has to do with whether the indicated
identity is believed to be a Good Actor or a Bad Actor.  The later reviews
attributes of the message, such as whether it promises a vigorous sex life, and
decides whether it is a legitimate message or an abusive one.

Entirely different functions.  The latter, of course, has nothing to do with
DKIM.  The former is the consumer of the identifier DKIM outputs.


> 9. d= tag definition
> 
> The corrected text removes the required relationship between the SDID and the
> AUID, which is perhaps repetitive of information in the i= tag definition,
> but which we felt important to repeat in the original

It was a forward reference, and yes repetitive, and it placed the requirement
into the functionality that isn't responsible for making the relationship
happen.  That is, the requirement is on i=, not on d=.  So that's where the
specification of the requirement is now placed.

Stated differently:  d= doesn't care whether i= conforms.  d= doesn't really
even "know" about i=.  On the other hand, i= is required to relate to d= by
being a sub-domain of it.




> 10. i= tag definition
> 
> paragraph 2, simple change:
> 
> OLD:
> 
> value of the "d=" tag.
> 
> NEW:
> 
> SDID.
> 
> [There are probably many more places in 4871 where words like this could be
> changed to the new terminology.  Should this update those as well, for
> clarity?]


oops.  good catch!  (I tried to fully audit the text for exactly this but pretty
much never get all the occurrences during such an exercise.  Thanks!.


> =
> 
> 11. Signing by Parent Domains
> 
> Small change, also in the original text:
> 
> OLD:
> 
> domain of the AUID ("i=" flag)
> 
> NEW:
> 
> domain of the AUID ("i=" value)

Oops.  But actually, neither of us got it right.  According to 4871, it's a 
"tag".


> =
> 
> 12. Relationship between SDID and AUID
> 
> This is another place where I'm having a problem with the premise that all a
> verifier needs to output is the SDID.


Since all of the finished DKIM documents offer the deliver of an identifier as
its only goal, are you suggesting explicitly expanding DKIM's scope?


> This section is engaging in considerable discussion about the relationship of
> the SDID and UAID to each other and to other header fields, most of which is
> not actionable by implementers of the DKIM base specification and in any case
> is covered elsewhere in the specification.

The section is intended to counteract a couple of years of confusion.


> NEW:
> 
> The SDID and AUID represent two different identifiers that may be relevant to
> assessors. 

Might be, yes.  All sorts of things /might/ be relevant to the heuristic 
evaluation engine.  But that's outside the scope of DKIM.  DKIM's job is to 
deliver an identifier.


> Unlike the SDID, the AUID, or parts of it, represents an
> assertion on the part of the signer whose meaning is not defined by this
> specification. 

parts of it???

assertion?  it's an identifier.  the only assertion the spec suggests is that 
it 
  can be used to identify a user -- although that's a bit problematic if it is 
only a domain name.

>The assessor MUST consider AUID values in
> the context of being an assertion:  

There is no requirement that the assessor see it and certainly no requirement 
that the assessor process it, nevermind process it in a particular way.


> The AUID local-part and any subdomain of the SDID used in the AUID are, in
> general, opaque.  Signing domains MAY make specific practices known regarding
> their use of the AUID, such as that it does represent an actual email
> address, but in the absence of such assertions MUST NOT be assumed by the
> assesso

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[SM]

Hi Eliot,
At 00:30 22-03-2009, Eliot Lear wrote:
>This would be reaching goals for the sake of reaching goals.  I 
>would note that an update isn't in the charter at all.  I'm not 
>saying don't do it.  I'm saying that I would rather

Without goals, we don't have a clear path stating what we want to 
achieve.  I don't think that we should reach goals for the sake of 
reaching them.

>the group re-examine its goals and decide what the right approach 
>is.  Is there a dependency on the proposed changes to get ADSP out 
>the door, for instance?  What about the readability of the document 
>series?  Can one simply write an update that attempts to cut and 
>paste from the original without adding confusion?

I'll skip your question about ADSP for now.  Before doing any change, 
we should take into account its effect on the document series.

>And now that this is going to be a full blown update or -bis effort, 
>what can be revisited?  For instance, the approach I proposed, and 
>many of my objections to the approach Dave and others proposed, was 
>based on the notion that we were discussing an errata document and 
>not a standards-track I-D.  If we are to have a standards-track I-D, 
>as I wrote quite some time ago, we have more leeway in changing 
>DKIM.  For instance, what is the proper way to deal with i= as a 
>component of the standard?  Should we deprecate it?

I agree with your point about having more leeway if we are discussing 
a Standards-Track I-D.  There has been discussions about making DKIM 
leaner by dropping some components.  If we drop i=, then we introduce 
a change that affects ADSP.

>This, by the way, is one of the problems I have with the chairs' 
>approach.  We (those who opposed the draft) were asked to tweak 
>specific lines in the doc, while at the same time being told that 
>the draft's final disposition is being changed by the AD.

I won't question the Chairs' approach.

>I still have other concerns.  Ultimately I think there is a downside 
>to being too constraining (the argument that John made earlier), 
>that people will ignore the constraints.  For instance, in this 
>case, it's pretty clear that many people will ignore some of the 
>terminology and just take d=, Sender:, From:, and potentially l= and 
>the length, as inputs to identity assessment.  And then they will 
>use i= anyway.
>Saying otherwise, IMHO, *is* premature.  Whatever.  You're 
>attempting to standardize secret sauce.  Here's news: some people's 
>secret sauce tastes bad (I always disliked Burger King's myself).

In my opinion, people will take whatever input they view as useful 
for an assessment.  There is nothing we can do about that except to 
say "don't do it".  John Levine made a good point about interoperability.

Regards,
-sm 

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Eliot Lear]

SM, all,

> It
> would be better for the DKIM WG to meet its goals before starting a
> discussion about Draft Standard.
>

This would be reaching goals for the sake of reaching goals.  I would 
note that an update isn't in the charter at all.  I'm not saying don't 
do it.  I'm saying that I would rather the group re-examine its goals 
and decide what the right approach is.  Is there a dependency on the 
proposed changes to get ADSP out the door, for instance?  What about the 
readability of the document series?  Can one simply write an update that 
attempts to cut and paste from the original without adding confusion?

And now that this is going to be a full blown update or -bis effort, 
what can be revisited?  For instance, the approach I proposed, and many 
of my objections to the approach Dave and others proposed, was based on 
the notion that we were discussing an errata document and not a 
standards-track I-D.  If we are to have a standards-track I-D, as I 
wrote quite some time ago, we have more leeway in changing DKIM.  For 
instance, what is the proper way to deal with i= as a component of the 
standard?  Should we deprecate it?

This, by the way, is one of the problems I have with the chairs' 
approach.  We (those who opposed the draft) were asked to tweak specific 
lines in the doc, while at the same time being told that the draft's 
final disposition is being changed by the AD.

I still have other concerns.  Ultimately I think there is a downside to 
being too constraining (the argument that John made earlier), that 
people will ignore the constraints.  For instance, in this case, it's 
pretty clear that many people will ignore some of the terminology and 
just take d=, Sender:, From:, and potentially l= and the length, as 
inputs to identity assessment.  And then they will use i= anyway.  
Saying otherwise, IMHO, *is* premature.  Whatever.  You're attempting to 
standardize secret sauce.  Here's news: some people's secret sauce 
tastes bad (I always disliked Burger King's myself).

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[SM]

At 13:42 20-03-2009, Barry Leiba wrote:
>What path we take to publish the errata beyond the ID that it is now,
>and whether the WG is behind publishing it without Pasi's (or the
>IESG's) approval, are things we'll be discussing in San Francisco and
>on the mailing list.  I hope that when we leave SF we'll have most of
>the answer to these, which answer we'll confirm on the mailing list.

Pasi mentioned that the errata should not be marked as "Approved" 
using the errata process.  He proposed getting the changes through 
the normal IETF consensus process, and published using the normal 
mechanisms we use for publishing updates to IETF work.

The agenda for the upcoming meeting has an item of discussion about 
WG-approved errata vs "update" RFC vs "replacement" RFC.  It may be 
better to stop using the term "errata" or "WG-approved errata" unless 
the WG is still considering submitting the ID or a variant of it as a 
proper errata.  Let's call it "RFC update".

We had a long debate over the last month about RFC 4871.  I think 
that it is premature to consider Draft Standard.  I note that SSP and 
the Overview document were set for WGLC in November 2007 according to 
the charter.  The Deployment document is still work in progress.  It 
would be better for the DKIM WG to meet its goals before starting a 
discussion about Draft Standard.

Regards,
-sm 

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Jim Fenton]

John Levine wrote:
>> The output of DKIM verification is considerably more than that:
>> there are a great many values, such as the list of signed header
>> fields, that may be useful to an assessor and that must be made
>> available to the assessor if the verifier is to be as interoperable
>> with as many assessors as possible.
>> 
>
> We seem to have a fairly basic disconnect here.  As far as I'm
> concerned, an assessor has better things to worry about than the
> internal details of the signature. Trying to reverse engineer or guess
> what the signer had in mind would be a hopeless swamp even if it were
> desirable.
>   

On the other hand, we definitely don't have enough information about
assessors to know what information they need.  Saying that the SDID is
the only thing they can depend on getting from the verifier is too
constraining.

> Sure, it's possible to put on a worthless signature that leaves out
> crucial headers, but signers who do so won't get a very good
> reputation so the problem should be self-limiting.  There's no
> existing installed base of inept signers we have to work around, and
> it would be a poor idea do anything that would allow crummy signatures
> to appear to work.
>   

The "worthless signature" may not have been so worthless if one of the
header fields in question wasn't present at the time of signing, but was
added later.  There have been proposals to convey some information
relating to assessment (for example, Jon Callas's suggestion at
http://mipassoc.org/pipermail/ietf-dkim/2009q1/011104.html ) by putting
it in a separate header field and signing it.  Are you suggesting that
whether that header field is signed or not is irrelevant to the assessor?

-Jim

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[HLS]

On 3/20/09, Michael Thomas  wrote:

> John R. Levine wrote:
>> Assessors know whether a message is signed, and if it has valid
>> signature(s), the domain(s) that signed them.  All that other stuff in the
>> signature is implementation details.
>
> RFC 4871 gives no precise definition of what an "assessor"
> can use to make whatever decisions it wants to draw from
> the message *and* the signature(s). That you have a particular
> use case in mind that doesn't care about "implementation
> details" does not and should not imply that that is the only
> valid use of DKIM information. That is why the errata is so
> wrong headed.

+1

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[John R. Levine]

> If assessors can't be bothered to assess the supposedly "self-limiting" 
> "implementation details", then reputation systems can not take them into 
> account. By definition.

Right.  That's a feature.  It's not my job to work around or even identify 
crappy signatures.  If there's junk in your signed mailstream, I'm not 
likely to accept your mail, regardless of how it got there.  I have no 
interest whatsoever in trying to pick apart signatures and guessing which 
ones are particularly gnarly and which ones are sort of froody.  They're 
either valid or they aren't, per 4871.

> RFC 4871 gives no precise definition of what an "assessor" can use to 
> make whatever decisions it wants to draw from the message *and* the 
> signature(s).

Right.  That's why we're clarifying it.

R's,
John

PS: So if if I'm wrong and assessors are going to use implementation 
details, how do you expect them to use the fact that this message has a 
signed Cleverness header?  Please be specific.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Michael Thomas]

John R. Levine wrote:
>>> We seem to have a fairly basic disconnect here.  As far as I'm
>>> concerned, an assessor has better things to worry about than the
>>> internal details of the signature. Trying to reverse engineer or guess
>>> what the signer had in mind would be a hopeless swamp even if it were
>>> desirable. ...
>
>> If assessors can't be bothered, then how will reputation systems know 
>> the
>> difference?
>
> Sorry, but I have no idea what the antecedent to this question is 
> supposed to be.  The difference between what and what?
>
>
>
You wrote:

> Sure, it's possible to put on a worthless signature that leaves out
> crucial headers, but signers who do so won't get a very good
> reputation so the problem should be self-limiting.  There's no
> existing installed base of inept signers we have to work around, and
> it would be a poor idea do anything that would allow crummy signatures
> to appear to work.

If assessors can't be bothered to assess the supposedly
"self-limiting" "implementation details", then reputation 
systems can not take them into account. By definition.

> Assessors know whether a message is signed, and if it has valid 
> signature(s), the domain(s) that signed them.  All that other stuff in the 
> signature is implementation details.

RFC 4871 gives no precise definition of what an "assessor"
can use to make whatever decisions it wants to draw from
the message *and* the signature(s). That you have a particular
use case in mind that doesn't care about "implementation
details" does not and should not imply that that is the only
valid use of DKIM information. That is why the errata is so
wrong headed.

Mike



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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[John R. Levine]

>> We seem to have a fairly basic disconnect here.  As far as I'm
>> concerned, an assessor has better things to worry about than the
>> internal details of the signature. Trying to reverse engineer or guess
>> what the signer had in mind would be a hopeless swamp even if it were
>> desirable. ...

> If assessors can't be bothered, then how will reputation systems know the
> difference?

Sorry, but I have no idea what the antecedent to this question is supposed 
to be.  The difference between what and what?

Assessors know whether a message is signed, and if it has valid 
signature(s), the domain(s) that signed them.  All that other stuff in the 
signature is implementation details.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Michael Thomas]

John Levine wrote:
>> The output of DKIM verification is considerably more than that:
>> there are a great many values, such as the list of signed header
>> fields, that may be useful to an assessor and that must be made
>> available to the assessor if the verifier is to be as interoperable
>> with as many assessors as possible.
>> 
>
> We seem to have a fairly basic disconnect here.  As far as I'm
> concerned, an assessor has better things to worry about than the
> internal details of the signature. Trying to reverse engineer or guess
> what the signer had in mind would be a hopeless swamp even if it were
> desirable.
>
> Sure, it's possible to put on a worthless signature that leaves out
> crucial headers, but signers who do so won't get a very good
> reputation so the problem should be self-limiting.  There's no
> existing installed base of inept signers we have to work around, and
> it would be a poor idea do anything that would allow crummy signatures
> to appear to work.
>
>   
If assessors can't be bothered, then how will reputation systems know the
difference? You really can't have it both ways.

In any case, this is a false dilemma; it's not just "crummy signatures" 
at issue.
And what you call a "hopeless swamp," I call "RFC 4871."

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[John Levine]

> The output of DKIM verification is considerably more than that:
> there are a great many values, such as the list of signed header
> fields, that may be useful to an assessor and that must be made
> available to the assessor if the verifier is to be as interoperable
> with as many assessors as possible.

We seem to have a fairly basic disconnect here.  As far as I'm
concerned, an assessor has better things to worry about than the
internal details of the signature. Trying to reverse engineer or guess
what the signer had in mind would be a hopeless swamp even if it were
desirable.

Sure, it's possible to put on a worthless signature that leaves out
crucial headers, but signers who do so won't get a very good
reputation so the problem should be self-limiting.  There's no
existing installed base of inept signers we have to work around, and
it would be a poor idea do anything that would allow crummy signatures
to appear to work.

R's,
John

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Scott Kitterman]

On Fri, 20 Mar 2009 16:42:30 -0400 Barry Leiba  wrote:
>Mike says...
>> Dave CROCKER wrote:
> Based on Pasi's comments, I had thought we were going the RFC route.
>>>
>>> Well, he has a preference for /only/ going that route, but he can't
>>> actually veto our issuing the Errata under the Errata mechanism.  Anyone can
>>> post anything they want under the Errata mechanism.  Some pretty silly stuff
>>> has gotten posted, over the years.
>>
>> I believe that what Dave is suggesting is an end run around the IESG.
>> In which case, I suggest that the working group insist on s/our/my/g;
>> above so that it has similar status.
>
>Mike, I take what you're saying to mean that you don't think the
>working group is behind "an end run around the IESG", and that the
>errata should not be saying that it is.
>
>What path we take to publish the errata beyond the ID that it is now,
>and whether the WG is behind publishing it without Pasi's (or the
>IESG's) approval, are things we'll be discussing in San Francisco and
>on the mailing list.  I hope that when we leave SF we'll have most of
>the answer to these, which answer we'll confirm on the mailing list.
>
>I think we need the high-bandwidth discussion, with Pasi in the room
>and responding, to get this point resolved in a way that doesn't leave
>everyone waving scimitars at everyone else.  We need to be discussing
>things productively as we go into final processing of ADSP and into
>4871bis and Draft Standard consideration.  (I'm going to try to get a
>conference call set up and use Skype and a microphone to allow remote
>participants to talk.  I know we've failed at that before, but I want
>to try again.)
>
>So while I'm on the cooperation and productivity bit
>To everyone: Please say what you mean calmly and clearly, so there's
>less chance of misunderstanding or the taking of offense where none
>was meant.  And please don't mean offense, either, of course.  "Digs",
>snarkiness, and passive-aggressiveness won't keep us moving forward.
>

Then in the spirit of plain speaking:

I do think that the current draft attempts to alter IETF consensus via the 
erata process in a way that is inappropriate.

While I think that Mike's objection was formulated in a way that unfortunately 
strucutred around personality, I agree that the content to which he was 
referring should be dropped from an eratum and addressed when the RFC is 
revised.

Scott K

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Barry Leiba]

>> So while I'm on the cooperation and productivity bit
>> To everyone: Please say what you mean calmly and clearly, so there's
>> less chance of misunderstanding or the taking of offense where none
>> was meant.  And please don't mean offense, either, of course.  "Digs",
>> snarkiness, and passive-aggressiveness won't keep us moving forward.
>
> Barry, what prompted this?

Nothing terribly special... mostly two points:

1. The way Mike made his point left lots of room for people to take it
in different ways, and I wanted to remind folks to be clear.

2. Over time, various participants have angered various others, often
leading to offline (and sometimes online) complaints.

I just wanted to use the opportunity to remind everyone that snark
doesn't help, even if it momentarily makes one feel good.  The
reminder wasn't addressed specifically.

Barry

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Jim Fenton]

On March 10, 2009, I wrote:
> DKIM Chair wrote:
>   
>> To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that 
>> we 
>> will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other 
>> choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as 
>> written?  If not, will you post specific changes, in OLD/NEW format, that 
>> would 
>> make it acceptable to you?  Acceptable changes must keep the sense of the 
>> draft-ietf-dkim-rfc4871-errata document with regard to the new terminology.
>>   
>> 
>
> I can do that, but it will probably take a few days.
Here are the rest of my comments on the draft.  My comments are based on
draft-ietf-dkim-rfc4871-errata-02 with the additional change from UAID
to AUID.  Perhaps "user or agent" should also change to "agent or user"
but I'm neutral on that.

0. Change the title to "RFC 4871 Update" if it is not being processed
using the errata process per Pasi's comments.

=

1. Introduction.  The introduction, particularly paragraphs 2 and 3,
assert that the payload (the output of DKIM verification) is only a
validated signing domain.  The output of DKIM verification is
considerably more than that:  there are a great many values, such as the
list of signed header fields, that may be useful to an assessor and that
must be made available to the assessor if the verifier is to be as
interoperable with as many assessors as possible.  Furthermore, not
requiring a verifier to output unknown tag/values makes DKIM
non-extensible:  What's the point of adding new tag/value definitions if
all the verifier is going to output is the SDID?

RFC 4871 somewhat narrowly defines a protocol between the signer and
verifier.  It does not define the semantics of everything that DKIM
might convey; that was left for the overview and/or operations
documents.  To say that RFC 4871 has the potential for non-interoperable
interpretations of how DKIM operates is to criticize the specification
for something that is out of its scope.

Suggested change:  Replace everything beginning with paragraph 2 of the
introduction with the following (and delete the remainder of the
introduction):

NEW:

Hence, DKIM has a signer that applies a signature to a message, a
verifier that confirms the signature, and DKIM interfaces with an
assessor what consumes the validated signing information.  This document
attempts to clarify the meaning of identifier fields appearing in the
DKIM signature to arrive at a more consistent use of these fields by
verifiers.

=


6. SDID definition

I am confused by the definition of the SDID as opaque.  This makes it
sound like it's a pseudonym for the actual signing domain.  The fact
that it's possible to look up information about the SDID using DNS
doesn't seem opaque to me.

OLD: A single, opaque value that is the mandatory payload output of DKIM

NEW: A single value that is a mandatory payload output of DKIM

=

7. AUID definition

Portions of the AUID are opaque, but not the whole thing because it has
to have a specified relationship with the SDID.  I would also clarify
that there is always an AUID, even if it isn't explicitly specified in
the signature and takes its default value.

OLD: A single, opaque value that identifies the user or agent on behalf
of whom the SDID has taken responsibility.  It is specified in Section 3.5.

NEW: A single value that identifies that agent or user on behalf of
which the SDID has taken responsibility.  The AUID has the syntax of an
email address, although the local-part and any subdomain of the SDID
which is used are opaque values which may not actually exist nor have
any relationship with other identifiers in the message.  It is specified
in Section 3.5.  The AUID takes the default value specified if it is not
explicitly present in the signature.

=

8. Identity Assessor

The term is imprecise:  it is not assessing an identity but a message. 
Suggest replacing this name with just "assessor" as is used in the
Introduction.

=

9. d= tag definition

The corrected text removes the required relationship between the SDID
and the AUID, which is perhaps repetitive of information in the i= tag
definition, but which we felt important to repeat in the original
document for emphasis.  The narrative about "conventions and semantics"
does not belong in the normative text describing the tag, and I'm not
clear what it's trying to say in any case.  The text also repeats much
of the wording in the definition of SDID about claiming responsibility
and such.

NEW:

The SDID of the signing entity (plain-text; REQUIRED).  This is the
domain that will be quieried for the public key.  The SDID MUST be the
same as or a parent of the domain in the AUID (the "i=" value, as
described below) and MUST meet the requirements for parent domain
signing described in Section 3.8.  When presented with a signature that
does not meet these requirement, verifiers MUST consider the signature
invalid.

=

10. i=

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Dave CROCKER]

Barry Leiba wrote:
> So while I'm on the cooperation and productivity bit
> To everyone: Please say what you mean calmly and clearly, so there's
> less chance of misunderstanding or the taking of offense where none
> was meant.  And please don't mean offense, either, of course.  "Digs",
> snarkiness, and passive-aggressiveness won't keep us moving forward.



Barry, what prompted this?

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] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Michael Thomas]

Barry Leiba wrote:
> Mike says...
>> Dave CROCKER wrote:
> Based on Pasi's comments, I had thought we were going the RFC route.
>>> Well, he has a preference for /only/ going that route, but he can't
>>> actually veto our issuing the Errata under the Errata mechanism.  Anyone can
>>> post anything they want under the Errata mechanism.  Some pretty silly stuff
>>> has gotten posted, over the years.
>> I believe that what Dave is suggesting is an end run around the IESG.
>> In which case, I suggest that the working group insist on s/our/my/g;
>> above so that it has similar status.
> 
> Mike, I take what you're saying to mean that you don't think the
> working group is behind "an end run around the IESG", and that the
> errata should not be saying that it is.

Close. I'm saying that it toes the line of completely inappropriate
for a _working group_ to consider an end run around the IESG, and
that we ought not consider that as an option for the working group.

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Barry Leiba]

Mike says...
> Dave CROCKER wrote:
 Based on Pasi's comments, I had thought we were going the RFC route.
>>
>> Well, he has a preference for /only/ going that route, but he can't
>> actually veto our issuing the Errata under the Errata mechanism.  Anyone can
>> post anything they want under the Errata mechanism.  Some pretty silly stuff
>> has gotten posted, over the years.
>
> I believe that what Dave is suggesting is an end run around the IESG.
> In which case, I suggest that the working group insist on s/our/my/g;
> above so that it has similar status.

Mike, I take what you're saying to mean that you don't think the
working group is behind "an end run around the IESG", and that the
errata should not be saying that it is.

What path we take to publish the errata beyond the ID that it is now,
and whether the WG is behind publishing it without Pasi's (or the
IESG's) approval, are things we'll be discussing in San Francisco and
on the mailing list.  I hope that when we leave SF we'll have most of
the answer to these, which answer we'll confirm on the mailing list.

I think we need the high-bandwidth discussion, with Pasi in the room
and responding, to get this point resolved in a way that doesn't leave
everyone waving scimitars at everyone else.  We need to be discussing
things productively as we go into final processing of ADSP and into
4871bis and Draft Standard consideration.  (I'm going to try to get a
conference call set up and use Skype and a microphone to allow remote
participants to talk.  I know we've failed at that before, but I want
to try again.)

So while I'm on the cooperation and productivity bit
To everyone: Please say what you mean calmly and clearly, so there's
less chance of misunderstanding or the taking of offense where none
was meant.  And please don't mean offense, either, of course.  "Digs",
snarkiness, and passive-aggressiveness won't keep us moving forward.

Barry
-- 
Barry Leiba, DKIM working group chair  (barryle...@computer.org)

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Siegel, Ellen]

Thanks, all, for the clarification. I read too quickly and missed the semantic 
distinction between "IETF consensus" was and "IETF working group consensus".

Ellen

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of SM
> Sent: Friday, March 20, 2009 2:39 PM
> To: DKIM Mailing List
> Subject: Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-
> errata
> 
> At 09:41 20-03-2009, Siegel, Ellen wrote:
> >OK, now I'm confused. Can someone define IETF rough consensus? The errata
> had
> >a 2/3 majority after the last round of discussion... does the IETF
> >ever get a better
> >consensus than that?
> 
> The Standards Process requires that a proposed standard be reviewed
> by the IETF community to establish whether it has the
> consensus.  This Working Group, for example, is only a subset of the
> IETF community.  The Working Group can be used to to determine
> whether it is worth asking the IETF community to review a
> proposal.  However, it cannot act as a substitute for the IETF community.
> 
> There isn't a formal definition of "IETF rough consensus".  From the Tao:
> 
>"a simple version is that it means that strongly held objections
> must be debated
> until most people are satisfied that these objections are wrong"
> 
> Regards,
> -sm
> 
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Michael Thomas]

Dave CROCKER wrote:
>>> Based on Pasi's comments, I had thought we were going the RFC route.
> 
> Well, he has a preference for /only/ going that route, but he can't actually 
> veto our issuing the Errata under the Errata mechanism.  Anyone can post 
> anything they want under the Errata mechanism.  Some pretty silly stuff has 
> gotten posted, over the years.

I believe that what Dave is suggesting is an end run around the IESG.
In which case, I suggest that the working group insist on s/our/my/g;
above so that it has similar status.

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[SM]

At 09:41 20-03-2009, Siegel, Ellen wrote:
>OK, now I'm confused. Can someone define IETF rough consensus? The errata had
>a 2/3 majority after the last round of discussion... does the IETF 
>ever get a better
>consensus than that?

The Standards Process requires that a proposed standard be reviewed 
by the IETF community to establish whether it has the 
consensus.  This Working Group, for example, is only a subset of the 
IETF community.  The Working Group can be used to to determine 
whether it is worth asking the IETF community to review a 
proposal.  However, it cannot act as a substitute for the IETF community.

There isn't a formal definition of "IETF rough consensus".  From the Tao:

   "a simple version is that it means that strongly held objections 
must be debated
until most people are satisfied that these objections are wrong"

Regards,
-sm 

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Douglas Otis]

On Mar 20, 2009, at 9:55 AM, Barry Leiba wrote:
>
> Pasi's point is that what you're quoting is from the DKIM working  
> group only, and, at that, only from some 20 participants or so.   
> There are a lot more people who participate in the IETF, and the  
> normal process of review by the IESG and IETF last call provides the  
> opportunity for many more people to review and comment on the  
> document.

The concern seemed more related to making definitional changes to an  
an RFC within an errata.

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Douglas Otis]

On Mar 19, 2009, at 11:22 PM, DKIM Chair wrote:

> The chairs appreciate the view that the "errata" draft makes a lot  
> of changes.
> Nevertheless, the view that those changes are too great... is quite  
> a minority
> view.  The only concrete objection we've seen in this latest round  
> is about the
> "UAID" term, and that appears to be resolved by making it "AUID".
>
> Beyond that, I've seen no clear objections and no alternative text  
> proposed.
> Rough consensus appears to be with the "errata" draft, with the  
> "AUID" change
> made to it.  So there it is.

There have been suggested changes to the text that was made  
previously.  There did not seem to be a reason to repeat the same  
objections and proposed changes when there did not appear to be  
agreement on going forward with portions of the errata that change  
prior definitions.

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Dave CROCKER]

Siegel, Ellen wrote:
> OK, now I'm confused. Can someone define IETF rough consensus? The errata had
> a 2/3 majority after the last round of discussion... does the IETF ever get a 
> better
> consensus than that? 

There's a difference between "IETF rough consensus" versus "Working Group rough 
consensus".  The vote we just took measures the latter.

To evaluate IETF consensus requires an IETF-wide Last Call and an IESG 
assessment of the results.


>> Based on Pasi's comments, I had thought we were going the RFC route.

Well, he has a preference for /only/ going that route, but he can't actually 
veto our issuing the Errata under the Errata mechanism.  Anyone can post 
anything they want under the Errata mechanism.  Some pretty silly stuff has 
gotten posted, over the years.

What Pasi /can/ do and has done is offer his assessment of the likely IESG 
decision about the /status/ that would be assigned to the Errata.

In particular, he has a reading of the IESG rules for Errata which says that 
anything that is controversial cannot be "approved".

Unfortunately, I think his interpretation of the relevant rule's text is 
reasonable, based on the latest explanation he provided.  I think it's a bad 
rule and should be changed, but dealing with that is different from debating 
his 
interpretation. In other words, I think he's providing a reasonable 
interpretation of a bad rule and that, for now, we have to live with it.

The alternative labels available to our Errata, if issued through the Errata 
mechanism, are "rejected" and "hold".  In my view, "hold", with text  in the 
Errata that states there is working group consensus, is sufficient.  Not ideal, 
but sufficient.  It provides an official publication channel sooner, rather 
than 
later.  Given wg approval, we aren't likely to see the label "rejected" get 
assigned...


> Given the likely time frame for an updated RFC (-bis or otherwise), I'd like 
> to make really
> sure that's the only option. Letting the Errata go through as errata and then 
> following
> up with the -bis seemed like the best option to me... something gets out 
> quickly, and 
> then the more complete update follows. 

+1

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] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Dave CROCKER]

DKIM Chair wrote:
> Beyond that, I've seen no clear objections and no alternative text proposed. 
> Rough consensus appears to be with the "errata" draft, with the "AUID" change 
> made to it.  So there it is.

I've placed a revised draft errata at:



which associates it directly to the original signing spec, RFC 4871.

It does the string replacement for AUID and it has a NOTE indicating working 
group approval.


>   I expect to spend the face-to-face time in 
> getting agreement on the mechanism to proceed (RFC vs non-IESG-approved 
> errata), 

Right.  "non-IESG-approved" is important phrasing.  Folks might realize that 
anyone can post anything they want under the errata mechanism.  The issue with 
IESG approval affects the status label that is associated with that entry. 
Anything other than "Rejected" is likely to serve our purposes, until the 
change 
is folded into RFC4871bis.

On the matter of whether to issue the Errata under Errata or defer its release 
further, we should consider how long the delay is likely to be, especially 
given 
the unspecified scope of RFC4871bis.

Some folks assume that the scope is trivially small, but a bis effort that is 
seeking Draft status can -- and, IMO, should -- carefuly review the 
specification and remove what has proven extraneous.

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] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Siegel, Ellen]

From: ietf-dkim-boun...@mipassoc.org [ietf-dkim-boun...@mipassoc.org] On Behalf 
Of Jim Fenton [fen...@cisco.com]
Sent: Friday, March 20, 2009 10:56 AM
To: DKIM Chair
Cc: DKIM Mailing List
Subject: Re: [ietf-dkim] Moving to  consensus   on  
draft-ietf-dkim-rfc4871-errata


> The question of whether the "errata" draft's changes are too great
> relates to whether it can be processed using the errata process or
> whether it requires IETF rough consensus.  However, in
> http://mipassoc.org/pipermail/ietf-dkim/2009q1/011421.html , Pasi ruled
> that it requires IETF rough consensus because it might differ from the
> intended consensus when RFC 4871 was approved.  So isn't the question of
> the size of the changes moot?

OK, now I'm confused. Can someone define IETF rough consensus? The errata had
a 2/3 majority after the last round of discussion... does the IETF ever get a 
better
consensus than that? 

> Based on Pasi's comments, I had thought we were going the RFC route.

Given the likely time frame for an updated RFC (-bis or otherwise), I'd like to 
make really
sure that's the only option. Letting the Errata go through as errata and then 
following
up with the -bis seemed like the best option to me... something gets out 
quickly, and 
then the more complete update follows. 

I'm hoping we can have some discussion around this next week. 

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Barry Leiba]

> OK, now I'm confused. Can someone define IETF rough consensus? The errata had
> a 2/3 majority after the last round of discussion... does the IETF ever get a 
> better
> consensus than that?

Pasi's point is that what you're quoting is from the DKIM working
group only, and, at that, only from some 20 participants or so.  There
are a lot more people who participate in the IETF, and the normal
process of review by the IESG and IETF last call provides the
opportunity for many more people to review and comment on the
document.

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Jim Fenton]

DKIM Chair wrote:
> My apologies for the delay in this; I meant to send this early this week, 
> after 
> getting back in town, but... then I didn't get to it.
>
> The chairs appreciate the view that the "errata" draft makes a lot of 
> changes. 
> Nevertheless, the view that those changes are too great... is quite a 
> minority 
> view.  The only concrete objection we've seen in this latest round is about 
> the 
> "UAID" term, and that appears to be resolved by making it "AUID".
>   

The question of whether the "errata" draft's changes are too great
relates to whether it can be processed using the errata process or
whether it requires IETF rough consensus.  However, in
http://mipassoc.org/pipermail/ietf-dkim/2009q1/011421.html , Pasi ruled
that it requires IETF rough consensus because it might differ from the
intended consensus when RFC 4871 was approved.  So isn't the question of
the size of the changes moot?

> Beyond that, I've seen no clear objections and no alternative text proposed. 
> Rough consensus appears to be with the "errata" draft, with the "AUID" change 
> made to it.  So there it is.
>   

I still owe the list a more extensive set of comments, which I had
promised "in a few days".  I will send those today.

> We have time on the agenda next week for discussion of this, and I think that 
> item will be brief.  We have consensus on this text -- and yes, I note that 
> it's 
> given only grudgingly by some.  I expect to spend the face-to-face time in 
> getting agreement on the mechanism to proceed (RFC vs non-IESG-approved 
> errata), 
> and in discussing where ADSP is and how to proceed on that.
>   

Based on Pasi's comments, I had thought we were going the RFC route.

-Jim

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Michael Thomas]

DKIM Chair wrote:
> My apologies for the delay in this; I meant to send this early this week, 
> after 
> getting back in town, but... then I didn't get to it.
> 
> The chairs appreciate the view that the "errata" draft makes a lot of 
> changes. 
> Nevertheless, the view that those changes are too great... is quite a 
> minority 
> view.  The only concrete objection we've seen in this latest round is about 
> the 
> "UAID" term, and that appears to be resolved by making it "AUID".
> 
> Beyond that, I've seen no clear objections and no alternative text proposed. 
> Rough consensus appears to be with the "errata" draft, with the "AUID" change 
> made to it.  So there it is.

   Um, the reason I didn't say anything is because of how the question
   was phrased. Rather like: "would you prefer your poison on the rocks,
   or straight up?". As I've said many times, the non-Crocker-inserted
   parts of the errata are not controversial. Nuking his parts in the
   entirety would be by far the most expeditious and would easily fit
   within the errata framework.

   Only having the choice of a poison pill or nothing just plain sucks.

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[DKIM Chair]

My apologies for the delay in this; I meant to send this early this week, after 
getting back in town, but... then I didn't get to it.

The chairs appreciate the view that the "errata" draft makes a lot of changes. 
Nevertheless, the view that those changes are too great... is quite a minority 
view.  The only concrete objection we've seen in this latest round is about the 
"UAID" term, and that appears to be resolved by making it "AUID".

Beyond that, I've seen no clear objections and no alternative text proposed. 
Rough consensus appears to be with the "errata" draft, with the "AUID" change 
made to it.  So there it is.

We have time on the agenda next week for discussion of this, and I think that 
item will be brief.  We have consensus on this text -- and yes, I note that 
it's 
given only grudgingly by some.  I expect to spend the face-to-face time in 
getting agreement on the mechanism to proceed (RFC vs non-IESG-approved 
errata), 
and in discussing where ADSP is and how to proceed on that.

Barry

--
Barry Leiba, DKIM working group chair  (barryle...@computer.org)
http://internetmessagingtechnology.org/


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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Dave CROCKER]

Folks,

Two days later. Still haven't seen any other issues raised with the draft.

d/

Dave CROCKER wrote:
> Folks,
> Question to the working group...
> DKIM Chair wrote:
>> To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that 
>> we 
>> will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other 
>> choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as 
>> written?  If not, will you post specific changes, in OLD/NEW format, that 
>> would 
>> make it acceptable to you?  
> 
> 
> Unless I've missed or misread other postings, the only item lodged, so far, 
> has 
> been Jim Fenton's suggest that the UAID acronym be replaced, and discussion 
> about that is proceeding.
> 
> Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed?
> 
> 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] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Michael Thomas]

Scott Kitterman wrote:
> I won't propose any.  I don't have time to do a proper job of rewriting it.  
> I think it alters 
> the IETF conensus view via errata and adds needless complexity.  
> 
> Silence or lack of change proposals does not equate to thinking the current 
> draft is good.

+1

I think it's rather premature to presuppose that we have any sort of
consensus about any -bis changes as the people that those changes affect
are most likely completely clueless that a -bis document is even on the
working group's agenda. AFAIK it is not even in the _charter_, so how
could a more casual but interested party be expected to know?

At the very least, it seems to me that this decision can wait for
the meeting next week to get a sense of the room. Rechartering
and an update to the DKIM wg web page also seems like a prerequisite
to making -bis changes. After all, this working group was all but
winding down a month or two ago.

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Scott Kitterman]

On Wed, 11 Mar 2009 08:54:35 -0700 Dave CROCKER  wrote:
>Folks,
>
>Question to the working group...
>
>
>DKIM Chair wrote:
>> To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, 
that we 
>> will be using draft-ietf-dkim-rfc4871-errata to move forward, and the 
other 
>> choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata 
as 
>> written?  If not, will you post specific changes, in OLD/NEW format, that 
>> would 
>> make it acceptable to you?  
>
>
>Unless I've missed or misread other postings, the only item lodged, so far, 
>has 
>been Jim Fenton's suggest that the UAID acronym be replaced, and discussion 
>about that is proceeding.
>
>Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed?
>

I won't propose any.  I don't have time to do a proper job of rewriting it.  I 
think it alters 
the IETF conensus view via errata and adds needless complexity.  

Silence or lack of change proposals does not equate to thinking the current 
draft is good.

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Dave CROCKER]

Stephen Farrell wrote:
>> Is that (editorial) work ongoing?
> 
> I think it'd be great if Dave were willing to do that, but I could
> understand if he'd rather not.

I'm fine with continuing to edit the draft-ietf-dkim-rfc4871-errata for the 
working group.

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] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Dave CROCKER]

Jim Fenton wrote:
> Dave CROCKER wrote:
>> Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed?
> 
> I believe the Chairs requested that the other, non-controversial, errata
> be incorporated into this draft.  Is that (editorial) work ongoing?


No, they didn't:

> DKIM Chair wrote:
...
>> To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that 
>> we 
>> will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other 
>> choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as 
>> written?  If not, will you post specific changes, in OLD/NEW format, that 
>> would 
>> make it acceptable to you?  Acceptable changes must keep the sense of the 
>> draft-ietf-dkim-rfc4871-errata document with regard to the new terminology.

That does not mention a bis and it does not cite the items sitting in the RFC 
Editor's Errata queue.

I think there is some confusion about the resolution of 
draft-ietf-dkim-rfc4871-errata with the development of RFC4871bis.  And while 
there has been some reference to a bis effort, it's been consistently -- and I 
believe correctly -- kept separate.

Let's resolve the draft-ietf-dkim-rfc4871-errata content issues and then move 
on 
to focus on a bis effort.

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] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Stephen Farrell]

Jim Fenton wrote:
> Dave CROCKER wrote:
>> Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed?
>>   
> 
> I believe the Chairs requested that the other, non-controversial, errata
> be incorporated into this draft.  

I think we suggested it as an option rather than requested.

> Is that (editorial) work ongoing?

I think it'd be great if Dave were willing to do that, but I could
understand if he'd rather not.

S.

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Jim Fenton]

Dave CROCKER wrote:
>
> Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed?
>   

I believe the Chairs requested that the other, non-controversial, errata
be incorporated into this draft.  Is that (editorial) work ongoing?

-Jim

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Jim Fenton]

Dave CROCKER wrote:
>
> One of the tricks in choosing labels is to make sure they each have
> useful meaning, but also that they are different enough to avoid
> confusion.  Labels are intended to have mnemonic benefit.
[...]
>
>> User Agent Identifier (UAID)
> ...
>> the user or agent on behalf of whom the SDID has taken responsibility.
>
>
> Note that the latter definition is taken from the existing RFC4871 text:
>
>> Identity of the user or agent (e.g., a mailing list manager) on
>> behalf of
>> which this message is signed
>
>
> So the UAID term reflects the exact language of RFC 4871 that defines
> the identifier:  user or agent.

There's a significant difference between "User Agent" (as in Mail User
Agent) and "user or agent".  It is wrong to give the impression that the
MUA is doing the signing, or that the MUA is being identified by this.
>
> If the term is changed to "signing identifier" it will be semantically
> wrong and mnemonically confusing.  Wrong because it's not the domain
> doing the signing, per the definition of SDID, and confusing because
> the term is almost identical to SDID.

I'm open to other ideas, but "signing identifier" is a lot less
semantically wrong than "user agent identifier".  And I hadn't proposed
a mnemonic yet (SID is over used).  4871 currently uses "signing
identity" which isn't excessively lengthy; "signing identifier" is more
precise terminology and I'm not sure it needs an acronym either.

-Jim

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Dave CROCKER]

Folks,

Question to the working group...


DKIM Chair wrote:
> To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that 
> we 
> will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other 
> choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as 
> written?  If not, will you post specific changes, in OLD/NEW format, that 
> would 
> make it acceptable to you?  


Unless I've missed or misread other postings, the only item lodged, so far, has 
been Jim Fenton's suggest that the UAID acronym be replaced, and discussion 
about that is proceeding.

Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed?

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] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Pasi.Eronen]

Eliot Lear wrote:

> As to the chair's request, FWIW I *have* given Dave suggested
> changes, and I believe he has accepted some of them.  I must admit
> some confusion about the process at this point.  It seems that there
> is an outstanding request of Pasi about whether this draft can
> proceed.  Here are my questions:

Since "whether this draft can proceed" could be interpreted in
multiple ways, let me clarify slightly: assuming we have rough WG
consensus about the content, this definitely can proceed, using the
same process we normally use for drafts (IETF Last Call, IESG
Evaluation, RFC Editor queue, and finally RFC ).

> 1.  If it does proceed, what happens with rfc4871bis?  I would
> expect we get to have this whole discussion over again because new
> avenues open themselves up when we are talking about a revision to
> the standard, like deprecating i=, adding r=, and perhaps even
> eliminating the concept of UAID.

This depends on how the charter scopes the work item.

For example, IPSECME is currently working on IKEv2bis (4306bis),
which is quite tightly scoped in the charter:

  "A revision to IKEv2 (RFC 4306) that incorporates the clarifications
  from RFC 4718, and otherwise improves the quality of the
  specification, taking into account implementation and
  interoperability experience. In some cases, the revision may include
  small technical corrections; however, impact on existing
  implementations must be considered. Major changes and adding new
  features is beyond the scope of this work item. The starting point
  for this work is draft-hoffman-ikev2bis."

So, the "bis" draft has absolutely no new features (IPSECME WG is also
working on new features, but they're in separate documents), and no
technical changes that don't count as "small technical corrections"
(which BTW in many cases means just resolving internal inconsistencies
-- one part of the RFC conflicts with some other part, and both can't
be right -- one way or the other).

At other times, it could be better to have a more open charter
(allowing the WG to redesign the protocol if they so decide), but 
for 4871bis, I'd probably recommend something closer to the IPSECME
approach (new features go to separate documents, and no big changes 
in 4871bis either).

If we want to emphasize completing 4871bis quickly, the extreme
scoping would be "draft-ietf-dkim-rfc4871-errata-NN plus the errata
currently submitted to RFC Editor, no other changes". Another
possibility would be this plus "...and remove all features/options 
that don't have at least two independent and interoperable
implementations" (so it could be updated to Draft Standard).

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Eliot Lear]

Dave, all,

I think the problem isn't so much that you aren't being precise with 
UAID, but rather two fold:

1.  UA has an existing connotation that people will grab onto.  This in 
itself is mnemonically confusing.
2.  If you're going to add acronyms, let them be ones that either can be 
easily pronounced without having to spell them out.  I won't be in SF, 
but I'll be listening for just how people handle this one ;-)

Still I'm reticent to suggest a change and have a never-ending semantics 
discussion (see q. 2 below about urgency).   Here's what I'd like NOT to 
have happen.  I'd like not to have one term defined in -ter and then 
another term defined in -bis.  It's okay (and IMHO advisable) to drop 
terms, but let's not change them.

As to the chair's request, FWIW I *have* given Dave suggested changes, 
and I believe he has accepted some of them.  I must admit some confusion 
about the process at this point.  It seems that there is an outstanding 
request of Pasi about whether this draft can proceed.  Here are my 
questions:

1.  If it does proceed, what happens with rfc4871bis?  I would expect we 
get to have this whole discussion over again because new avenues open 
themselves up when we are talking about a revision to the standard, like 
deprecating i=, adding r=, and perhaps even eliminating the concept of UAID.

2 .  If it doesn't proceed, Dave has expressed urgency about having an 
erratum published.  I'd like to know if that is still the case, and what 
people believe the right approach to be.

3.  John has offered to rev. ADSP to handle r= instead of i=.  I wonder 
what other people think about that.

Eliot

On 3/11/09 12:55 AM, Dave CROCKER wrote:
> Jim Fenton wrote:
>
>> I have a particular problem with the term "User Agent Identifier (UAID)"
>> because it doesn't necessarily represent a user agent -- it could, for
>> example, represent a mailing list manager.  I greatly prefer the term
>> "signing identifier" (which replaces signing identity) because it covers the
>>   range of use cases more completely.
>>  
> One of the tricks in choosing labels is to make sure they each have useful
> meaning, but also that they are different enough to avoid confusion.  Labels 
> are
> intended to have mnemonic benefit.
>
> The two labels in the current Errata draft are defined as:
>
>
>> Signing Domain Identifier (SDID)
>>  
> ...
>
>> the identity claiming responsibility for the introduction of a message into
>> the mail stream.
>>  
> and
>
>
>> User Agent Identifier (UAID)
>>  
> ...
>
>> the user or agent on behalf of whom the SDID has taken responsibility.
>>  
> Note that the latter definition is taken from the existing RFC4871 text:
>
>
>> Identity of the user or agent (e.g., a mailing list manager) on behalf of
>> which this message is signed
>>  
> So the UAID term reflects the exact language of RFC 4871 that defines the
> identifier:  user or agent.
>
> If the term is changed to "signing identifier" it will be semantically wrong 
> and
> mnemonically confusing.  Wrong because it's not the domain doing the signing,
> per the definition of SDID, and confusing because the term is almost identical
> to SDID.
>
> d/
>
>

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Dave CROCKER]

Jim Fenton wrote:
> I have a particular problem with the term "User Agent Identifier (UAID)" 
> because it doesn't necessarily represent a user agent -- it could, for 
> example, represent a mailing list manager.  I greatly prefer the term 
> "signing identifier" (which replaces signing identity) because it covers the
>  range of use cases more completely.


One of the tricks in choosing labels is to make sure they each have useful 
meaning, but also that they are different enough to avoid confusion.  Labels 
are 
intended to have mnemonic benefit.

The two labels in the current Errata draft are defined as:

> Signing Domain Identifier (SDID)
...
> the identity claiming responsibility for the introduction of a message into 
> the mail stream.

and

> User Agent Identifier (UAID)
...
> the user or agent on behalf of whom the SDID has taken responsibility.


Note that the latter definition is taken from the existing RFC4871 text:

> Identity of the user or agent (e.g., a mailing list manager) on behalf of
> which this message is signed


So the UAID term reflects the exact language of RFC 4871 that defines the 
identifier:  user or agent.

If the term is changed to "signing identifier" it will be semantically wrong 
and 
mnemonically confusing.  Wrong because it's not the domain doing the signing, 
per the definition of SDID, and confusing because the term is almost identical 
to SDID.

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] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Jim Fenton]

DKIM Chair wrote:
> To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that 
> we 
> will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other 
> choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as 
> written?  If not, will you post specific changes, in OLD/NEW format, that 
> would 
> make it acceptable to you?  Acceptable changes must keep the sense of the 
> draft-ietf-dkim-rfc4871-errata document with regard to the new terminology.
>   

I can do that, but it will probably take a few days.  But for
clarification, is the new terminology cast in stone?  I have a
particular problem with the term "User Agent Identifier (UAID)" because
it doesn't necessarily represent a user agent -- it could, for example,
represent a mailing list manager.  I greatly prefer the term "signing
identifier" (which replaces signing identity) because it covers the
range of use cases more completely.

-Jim

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

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[Barry Leiba]

> I can do that, but it will probably take a few days.  But for
> clarification, is the new terminology cast in stone?  I have a
> particular problem with the term "User Agent Identifier (UAID)" because
> it doesn't necessarily represent a user agent -- it could, for example,
> represent a mailing list manager.  I greatly prefer the term "signing
> identifier" (which replaces signing identity) because it covers the
> range of use cases more completely.

I'd say it's a fair proposal, and we'll see where it goes.
What I meant was that, for example, it won't work to propose text
changes that roll back the terminology changes altogether.  Or
something like that.  A proposed change with a reason behind it gives
everyone something to work with and to decide, one way or t'other.

Barry

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

[ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

[DKIM Chair]

This thread has been split from Dave's long note.

Here's what I want to try, in order to convert the "majority vote" into what 
Stephen and I would be happy to call "rough consensus".  I have not discussed 
this yet with Stephen, in the interest of getting it out here more quickly, so 
he 
may feel free to object to this and whack me over the head (as Dave has already 
done).

As I said in my note summarizing where we are, the working group vote between 
the 
a/b/c/d choices has taken the simpler errata changes out of the mix and given 
us 
draft-ietf-dkim-rfc4871-errata as the path forward.  There were, though, enough 
votes against it for the chairs to consider it "significant", so:

To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that we 
will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other 
choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as 
written?  If not, will you post specific changes, in OLD/NEW format, that would 
make it acceptable to you?  Acceptable changes must keep the sense of the 
draft-ietf-dkim-rfc4871-errata document with regard to the new terminology.

Barry

--
Barry Leiba, DKIM working group chair  (barryle...@computer.org)
http://internetmessagingtechnology.org/


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