Subject: [apps-discuss] Revised DMARC working group charter proposal

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 12 Apr 2013 12:10:31 -0700

Hello again,

After discussion with some IESG members and the DMARC community, a revised
charter has now been posted for consideration:

http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

Thanks to everyone who provided constructive help in getting this reformed
into a palatable charter.  Please feel free to offer more comments; if it
seems non-upsetting, we'd like to ask the ADs to put it on a future
telechat.

Thanks,
-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Apr 2013 17:56 -0400

> seems non-upsetting, we'd like to ask the ADs to put it on a future

"The initial charter for this working group does not include revising the base 
specification"

I don't think removing the work on the base specification from the charter 
really addresses the concern that the previous draft charter over constrained 
work on the base charter.  "You have to recharter" to make a change seems very 
constraining.

At some point, if DMARC is going to be an IETF standard, dmarc.org is going to 
have to let go of change control.  I think this revision goes in the opposite 
direction.

There were a number of suggestions based on DKIM and other WG charters that 
seemed to me like a good basis for balancing the concerns of existing 
implementers with the idea of allowing an IETF working group to actually do 
work.

By removing the work from the working group entirely, I think this is the 
wrong direction to go in.

Scott K

---

From: "J. Trent Adams" <[email-masked]>
Date: Fri, 12 Apr 2013 19:12:00 -0600

To speak in favor of the newly revised charter, I believe that it is a
reasonable balance when considering the context. Specifically, a lot of
organizations already see real value in the current version of the base
specification.

That's not to say it can't be improved, but the stability of the version
at this stage of deployment is an important factor. It will be through
continued wide-spread adoption and feedback on real-world utility that
will help suggest improvements to the group.

The proposed charter does a good job of taking a pragmatic, lessons
learned type of approach. It considers the experience that only comes
from "running code", capturing what works (and documenting it), all the
while cataloging ways it can be improved. There is also lot of room for
work on important, non-disruptive extensions (some ideas for which are
included, while others will undoubtedly arise).

Then, once a reasonable amount of due diligence is performed by the
broader community, the group will have the data it needs to determine if
the base specification itself should be improved. If so, the group can
re-charter with that work in scope and the specification will be in it's
capable hands.

Basically, it seems to me that this is a very healthy approach in which
I look forward to participating.

Thanks,
Trent

On 4/12/13 3:56 PM, Scott Kitterman wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

-- 
J. Trent Adams

LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Apr 2013 19:20:42 -0700

Scott,

Would that these processes were more smooth. However...

> work on the base charter.  "You have to recharter" to make a change seems very

To charter a working group that will make changes to a specification, 
there first must be a sense of the kinds of changes that are needed and 
desired by the folks who will develop and deploy the changes.

Before bringing the spec to the IETF venue, we looked quite hard amongst 
the current DMARC community for a meaningful, near-term work-list to 
attempt on the base spec, and failed to develop one.

So Scott, what changes to the DMARC base spec are you seeking and why 
and who wants them and how do we know this?

> implementers with the idea of allowing an IETF working group to actually do

The issue is not whether random, thoughtful folk can imagine a range of 
changes to make.  The question is what is actually needed and by whom 
and what the basis for believing this is.

Start by considering that there is a recent installed base, which means 
that the folks currently deploying DMARC, to cover roughly 60% of the 
world's mailboxes, would like to recover their initial investment before 
making more changes.  Then consider that they haven't yet registered 
requests for changes or enhancements.  Then please explain the basis for 
changing to make more changes now?

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 13 Apr 2013 02:00:45 -0400

>and who wants them and how do we know this?

In part, I don't. DMARC has been developed in private by a relatively small group of people. I think it's not unreasonable to consider the spec might be improved by broader review.  Things that were written by people who already "know" what the spec is supposed to mean are often less clear to those outside the group. Until a broader group actually reviews it, there's no way to know. 

That's not a matter of changing the protocol, but improving the text.  I don't see any reason for existing implementers to fear improved text.

The one thing I think does need to be changed is the policy override approach.  Changing SPF policy based on DMARC is a layering violation at the very least. While reading the envelope (HELO/5321.Mail From) I have to change processing based information in the body (5322.From).  Many SPF implementations don't have access to the body making it difficult to implement correctly. 

Not only is the current design wrong, it's nor needed to solve the problem DMARC was meant to solve.

Similarly, due to this override, a DMARC policy of none can't be used just to collect data as it will change mail processing as well.

>changing to make more changes now?

The current design is wrong. The specific issues I'm concerned with now can be resolved without forcing existing implementers to change anything, so no investment is at risk.  Improving and clarifying the text of the spec is similarly not a risk.

Fundamentally, rubber stamping the work of a private design team is not the IETF way.  Your arguments can be applied to almost any technology brought to the IETF with an existing constituency. 

Given the current draft charter, I think a working group is pointless. 

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Sat, 13 Apr 2013 04:37:47 -0700

Scott,

On 4/12/2013 11:00 PM, Scott Kitterman wrote:
>> So Scott, what changes to the DMARC base spec are you seeking and
>> why and who wants them and how do we know this?
>
> In part, I don't. DMARC has been developed in private by a relatively
> small group of people. I think it's not unreasonable to consider the
> spec might be improved by broader review.

    It's entirely reasonable.  That's why the draft charter provides for 
such future effort: "However, if resolving any of the issues listed in 
the areas of focus below does require changes to the base specification, 
or if the specification needs to be revised to correct technical errors 
deemed essential for proper use, the group will recharter accordingly."

    The specification has been public for considerably more than a year, 
including a press release and a public discussion list, with adoption 
covering roughly 60% of the world's mailboxes.  That's not a small base 
of experience.  So there's been plenty of opportunity for community 
review and input, including requests for changes.  And yet, there is so 
far no such list of requests.

 >  Things that were written
> by people who already "know" what the spec is supposed to mean are
> often less clear to those outside the group. Until a broader group
> actually reviews it, there's no way to know.

   You are correct, of course.  However the range of implementers now 
goes considerably beyond the original group, and yet there is so far no 
concrete list of interesting changes being requested.

> That's not a matter of changing the protocol, but improving the text.

    Well, that's what we originally submitted for chartering, but at 
least one AD didn't like it.

> The one thing I think does need to be changed is the policy override
> approach.  Changing SPF policy based on DMARC is a layering violation
> at the very least.

    Sorry, but I'm missing the reference.  Please point to the section 
of text you don't like and describe the kind of change you are seeking.

(FWIW, on reflection, I'm not a fan of the term policy override, since 
it implies that the recipient has somehow been bound to conformance to 
the sender's policies...)

> While reading the envelope (HELO/5321.Mail From) I
> have to change processing based information in the body (5322.From).
> Many SPF implementations don't have access to the body making it
> difficult to implement correctly.

    If they are doing DMARC, they do have access.

> problem DMARC was meant to solve.

    Sounds like a protocol change.  That's rather more than merely 
improving the text.

> Similarly, due to this override, a DMARC policy of none can't be used
> just to collect data as it will change mail processing as well.

    I don't understand.

> The current design is wrong. The specific issues I'm concerned with
> now can be resolved without forcing existing implementers to change
> anything, so no investment is at risk.

    The idea that one can change a design, without having to change 
code, is new to me.  Please explain.

> Fundamentally, rubber stamping the work of a private design team is
> not the IETF way.

    What part of the work in the latest draft charter would produce 
rubber stamping?

    But since you are being pedagogical about how the IETF does things, 
please note that working group charters are supposed to specify the 
nature of the work to be done.  Working groups that start without a 
sense of what problem they are trying to solve to tend to have poor 
outcomes.  If you can specify the nature of the technical, work to be 
done, sufficiently to garner support for it, then it's certainly worth 
considering.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 13 Apr 2013 08:29:24 -0400

>least one AD didn't like it.

I'll respond to the balance of your message once I'm back at a computer since collecting the relevant references using just my phone would be excessively painful. 

Was the one AD that didn't like it the discussion on this list or elsewhere? If it was elsewhere, please provide a reference so we can understand the nature of the objection.

Scott K

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 13 Apr 2013 07:13:52 -0700

=====
The initial charter for this working group does not include revising the base specification, but rather producing incremental extensions to it. However, if resolving any of the issues listed in the areas of focus below does require changes to the base specification, or if the specification needs to be revised to correct technical errors deemed essential for proper use, the group will recharter accordingly.
=====

To me, this says "the WG should produce incremental extensions where needed". However:

=====
At the time of chartering, DMARC has already achieved an estimated coverage of 60% of the Internet's mailboxes. Consequently, any extensions or revisions that create software or operations incompatibilities with this significant installed base need to be considered carefully. The strong preference is for the working group to preserve existing software and procedures. For changes likely to affect the installed base, the working group will actively seek to include developers and operators of DMARC-based mechanisms outside the core set of working group participants in its consensus discussions.
=====

To me, that says that the WG cannot produce an incremental extension because existing software and procedures would have to be updated.  That statement seems to include even the listed milestones. For example, I cannot see how to make DMARC work with mailing lists without changing software and/or procedures. Similarly, even if there is agreement on transitive trust agreements will change procedures significantly.

If the people proposing the charter want a WG that extends the base spec, the latter paragraph needs to be removed. If the people proposing the charter want a WG that does not change the software and operations currently deployed, the first paragraph needs to be remove, and make it clear that the WG's only deliverables are the implementation and deployment guide and practices guides from later in the charter.

Having both paragraphs in the charter leaves the WG participants not knowing what it is they can do, and yet that knowing is exactly why the IETF has charters.

Assuming that the people proposing the charter really want the limitations from the second quote above (which seems likely), I propose that the WG not be formed. Forming a WG with limitations that are imposed from outside the IETF will cause the waste of hundreds or thousands of IETF participant hours. The phrase "needs to be considered carefully" is a call to endless debates about what "carefully" means and who ultimately gets to be the careful considerers who count.

The main proponents of the private DMARC spec are already active IETF participants. They can recruit the rest of us to join the private DMARC work effort without wasting a lot of IETF time on helping a private effort. They can send mail to AppsArea when they want people to join their private discussions on extensions to DMARC. They can (and should!) update people at the face-to-face IETF meetings. They can (and should!) publishing the results of their private efforts as RFCs through the ISE; that's a great use of the ISE track of RFCs. But trying to have an IETF WG-that-isn't-really-a-WG seems wasteful of valuable resources.

Note: if I'm wrong above and the people proposing the charter ditch the restrictions of the second quote, the charter still needs more work, namely adding a sentence or two to each deliverable about what is expected of those extensions.

--Paul Hoffman

---

From: Dave Crocker <[email-masked]>
Date: Sat, 13 Apr 2013 13:55:43 -0700

On 4/13/2013 5:29 AM, Scott Kitterman wrote:
> Was the one AD that didn't like it the discussion on this list or elsewhere?

This (apps-discuss) list.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 13 Apr 2013 14:01:14 -0700

On 4/13/2013 7:13 AM, Paul Hoffman wrote:
> To me, that says that the WG cannot produce an incremental extension because existing software and procedures would have to be updated.

Speaking for myself only, of course, but...

That's an unexpected interpretation of the text.

Normally, an "incremental extension" is taken to mean that it provides 
/additional/ capabilities that are not essential to core operation. 
(cf., smtp extensions or mime).

That is, whatever was original working will still work, albeit without 
whatever new and spiffy capabilities are specified in the incremental 
extensions.

By way of a marked contrast, cf. IPv4 vs. IPv6.

While I can certainly imagine a frame of mind that counts IPv6 as an 
"incremental extension" to IPv4, that frame of mind is certainly not the 
one intended for reading the draft charter.

To summarize:  the charter seeks to constrain work that might /force/ a 
change in the existing installed base, by virtue of creating an 
interoperability problem, rather than to necessarily constrain value-add 
enhancements that are optional.

d/

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 13 Apr 2013 15:06:51 -0700

Thanks, this is very helpful, and may make the charter proposal much more palatable.

On Apr 13, 2013, at 2:01 PM, Dave Crocker <[email-masked]> wrote:

> Normally, an "incremental extension" is taken to mean that it provides /additional/ capabilities that are not essential to core operation. (cf., smtp extensions or mime).

I would not say that is the "normal" definition of an incremental extension, but it is one that helps here. Given that, and the obvious distaste for revisions that would force changes in the deployed servers, would the following shorter paragraph be an acceptable replacement for the two paragraphs in question ("The initial charter..." and "At the time...")?

=====
The initial charter for this Working Group consists only of incremental extensions to the base specification.  An incremental extension is one that would allow an extended system to interoperate with an unextended system. This charter explicitly does not include revising the base specification. If creating any of the WG deliverables requires non-interoperable changes to the base specification, or if the specification needs to be revised to correct technical errors deemed essential for proper use, the group would need to recharter to revise the base specification in the specific areas needed.
=====

This wording removes the conflation of extensions and revisions in the current charter text, it removes sentences about why the WG should avoid rechartering, and makes it completely clear what the boundaries for the listed WG work items are.

Having said that, I think both the current text and my proposal above have a thorny constitutional problem: if the WG recharters to change a problem in the base specification, the WG would be working on an protocol that is an RFC that is outside the IETF Stream. I suspect that that should only be done if the result is bringing the revised base spec into the IETF Stream as an Standards Track document. But I think that issue can be noted here (not in the charter) and only raised if the recharter actually happens.

--Paul Hoffman

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 13 Apr 2013 16:25:41 -0700

On Sat, Apr 13, 2013 at 3:06 PM, Paul Hoffman <[email-masked]> wrote:

> Having said that, I think both the current text and my proposal above have
> a thorny constitutional problem: if the WG recharters to change a problem
> in the base specification, the WG would be working on an protocol that is
> an RFC that is outside the IETF Stream. I suspect that that should only be
> done if the result is bringing the revised base spec into the IETF Stream
> as an Standards Track document. But I think that issue can be noted here
> (not in the charter) and only raised if the recharter actually happens.
>
>
>
I'm pretty sure the intent is to publish the current base draft through the
ISE, since it was developed outside the IETF, but if it changes (via
rechartering), move it to the IETF stream.  The latter can obsolete the
former if the timing warrants doing so.  Thus, if the working group is ever
actually cracking open the base draft, it's on the IETF stream.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Sun, 14 Apr 2013 01:03:34 +0000

Daves comments match my understanding of the intent of the draft charter.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Dave Crocker
> Sent: Saturday, April 13, 2013 5:01 PM
> To: Paul Hoffman
> Cc: IETF Apps Discuss
> Subject: Re: [apps-discuss] DMARC and the conflict of extensions vs.
> deployment
> 
> 
> 
> > At the time of chartering, DMARC has already achieved an estimated
> coverage of 60% of the Internet's mailboxes. Consequently, any extensions
> or revisions that create software or operations incompatibilities with this
> significant installed base need to be considered carefully. The strong
> preference is for the working group to preserve existing software and
> procedures. For changes likely to affect the installed base, the working group
> will actively seek to include developers and operators of DMARC-based
> mechanisms outside the core set of working group participants in its
> consensus discussions.
> > =====
> >
> > To me, that says that the WG cannot produce an incremental extension
> because existing software and procedures would have to be updated.
> 
> 
> That is, whatever was original working will still work, albeit without whatever
> new and spiffy capabilities are specified in the incremental extensions.
> 
> "incremental extension" to IPv4, that frame of mind is certainly not the one
> intended for reading the draft charter.
> 
> change in the existing installed base, by virtue of creating an interoperability
> problem, rather than to necessarily constrain value-add enhancements that
> are optional.
> 
> d/
> --
>   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 15 Apr 2013 16:02:56 -0400

> far no such list of requests.

Not true.  There was a long thread, almost a year ago on the interaction of 
DMARC policy with policy aspects of other domain authentication technologies 
(SPF and DKIM/ADSP) that starts here:

http://www.dmarc.org/pipermail/dmarc-discuss/2012-July/001104.html

While some of the issues addressed in that thread have been addressed (the 
most critical one that DMARC policy of none should not alter processing for 
SPF or DKIM/ADSP in particular), I don't think the issue is fully resolved.  
Here's the current, relevant snippet from the draft submitted to the IETF:

>    DMARC-compliant Mail Receivers SHOULD disregard any mail directive
>    discovered as part of an authentication mechanism (e.g., ADSP, SPF)
>    where a DMARC policy is also discovered that specifies a policy other
>    than "none". {R7} To enable Domain Owners to receive DMARC feedback
>    without impacting existing mail processing, discovered policies of
>    "p=none" SHOULD NOT modify existing mail disposition processing.
>    Note that some Mail Receivers may reject email based upon SPF policy
>    mechanisms before email enters DMARC-specific processing.

I think the initial SHOULD represents a layering violation that is technically 
inappropriate from a design perspective, will substantially complicate 
implementation, and is not needed.  Details to follow.

> concrete list of interesting changes being requested.

The current implementers don't need the IETF spec.  The RFC should be oriented 
towards future implementers (Ironic note: I was on the other side if this 
exact question about 4408bis in SPFbis and lost - I am now convinced that this 
view is the right one).  

Absent a working group to actually do some independent review, there's no way 
of knowing what would come up.  The currently proposed charter, by design, 
minimizes the incentive to actually do so.  The only IETF review of the base 
spec would be a, by design, very limited scope review by the IESG.

> least one AD didn't like it.

Right, but the direction that the AD didn't like it was that the previous 
proposal constrained the working group too much.  Removing the work entirely 
from the working group seems like doing the opposite of addressing the 
concern.  It seemed to me that there were a number of reasonable suggestions, 
including coming from the AD in question, that did a nice job of balancing the 
concerns of existing implementers without handcuffing the proposed working 
group.  I think the current draft charter is an over-reaction in the wrong 
directions.

> the sender's policies...)

See the text quoted above for the specific reference.  

In order to implement DMARC it's necessary for the component of a mail system 
that does SPF processing to have access to the 5322.From extracted from the 
body of the message (because of the SHOULD to skip SPF related policy 
decisions for domains that have a DMARC policy != none and 5322.From provides 
the domain needed to determine if a DMARC policy is relevant for the message).

Requiring data from the message body to do operations on the envelope is not a 
good idea.

>     If they are doing DMARC, they do have access.

Eventually, but not necessarily when the SPF processing is done.

I have currently deployed DMARC verification for testing (I'm adding the 
relevant authentication results header fields, but not enforcing reject 
policies).  I'll use my current setup as a specific example of why following 
"SHOULD disregard any mail directive discovered as part of an authentication 
mechanism (e.g., ADSP, SPF)" adds substantial complexity to implementation and 
deployment due to the layering violation inherent in that requirement.

For this deployment, the MTA is Postfix, the SPF verifier is pypolicyd-spf, the 
DKIM verifier is opendkim, and the DMARC verifier is opendmarc.

Postfix has an "Access Policy Delegation" interface 
(http://www.postfix.org/SMTPD_POLICY_README.html) that is used by pypolicyd-spf 
to do SPF verification during the SMTP session.  SPF 5321.Mail From and HELO 
results are determined and, if the mail is not rejected/deferred, an 
appropriate Received-SPF or Authentication-Results header field is added.  This 
is done after mail from or rcpt to.

After the body of the message is received (after data), it is passed via the 
milter interface to opendkim for DKIM verification (which adds an 
Authentication-Results header field for DKIM) and then to opendmarc which also 
adds an appropriate Authentication-Results header field (since I'm not 
enforcing DMARC policy yet, it always just adds the field).

SPF checking via the "Access Policy Delegation" interface is the standard 
approach for Postfix deployments (in fact, the interface was specifically added 
to support SPF checking, although it is used for many other things as well).  
As is appropriate for an MTA, the policy interface operates on the envelope of 
the message and does not provide access to the body of the message, which 
typically has not been transmitted when it is invoked.

The requirement to have access to the body of the message to do SPF checking 
in a DMARC environment is an architectural mess.

>     Sounds like a protocol change.  That's rather more than merely

Yes, but not one that would require implementations to be changed to fix, which 
I think is the important point.  I believe that SHOULD/MAY in "SHOULD 
disregard any mail directive discovered as part of an authentication mechanism 
(e.g., ADSP, SPF)" is probably sufficient, but since they can already do that, I 
don't know what the point of even having it in the spec is.

> > just to collect data as it will change mail processing as well.

This particular aspect of the issue has been corrected in the current draft, 
sorry for dragging it in.

> code, is new to me.  Please explain.

If you change a SHOULD requirement to a MAY requirement then nothing forces 
existing implementations to change.  The can, but they don't have to.

> done, sufficiently to garner support for it, then it's certainly worth

I'm aware of one technical issue that I believe to be significant that needs to 
be addressed and wasn't addressed by the private design group.  Unless it's in 
scope for a working group to review the input of that work to the IETF, there 
is not likely to be the same level of review.

Additionally, I think it is very odd to submit the base spec as an independent 
submission and then form a working group to extend it.  As I understand it, 
part of a working group effort is to get consensus around technical efforts.  
I'm not sure how you get consensus to extend something for which there is no 
IETF consensus.  

I might even think that perhaps that the bit in RFC 4846 about the IESG review 
where it mentioned independent submissions shouldn't be an end run around the 
working group process might be relevant.  It also seems to me that if the 
DMARC base spec seeks to modify processing for IETF RFCs, it's pretty much 
inherently a conflict of the type that IESG review of independent submissions 
is supposed to identify.

I think that if DMARC were entirely laid on top of SPF/DKIM/ADSP and there was 
not also a parallel proposal for an IETF working group to extend DMARC, then 
independent submission would not be inappropriate, but I'd still prefer to see 
DMARC standardized through the IETF.  I think that there will be a better 
product as a result (and I also think it's not at all difficult to craft charter 
language that will adequately address the equities of early adopters).

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Apr 2013 17:15:32 -0700

Scott,

At the risk of this going too far afield from a chartering discussion --
it might be worth moving this thread to [email-masked]:

On 4/15/2013 1:02 PM, Scott Kitterman wrote:
>> The specification has been public for considerably more than a
>> year, including a press release and a public discussion list, with
>> adoption covering roughly 60% of the world's mailboxes.  That's not
>> a small base of experience.  So there's been plenty of opportunity
>> for community review and input, including requests for changes.
>> And yet, there is so far no such list of requests.
>
> Not true.  There was a long thread, almost a year ago on the
> interaction of DMARC policy with policy aspects of other domain
> authentication technologies (SPF and DKIM/ADSP) that starts here:
>

I apologize for being unclear.  I didn't mean that no individuals had
any requests.  I meant that there has been no demonstration of community
support -- a rough consensus kind of support -- for changes.

To my own reading, the thread you cite nicely demonstrates this:
community interest, community discussion, but no community support for 
change.  If you feel otherwise, please document it.

> While some of the issues addressed in that thread have been addressed
> (the most critical one that DMARC policy of none should not alter
> processing for SPF or DKIM/ADSP in particular), I don't think the
> issue is fully resolved.

I don't see that thread as having created items to be resolved.  Again,
feel free to document otherwise.

And given considerably more of one year for that public discussion, we
haven't identified any items that might show community support for
modifying the base specification.

>> discovered as part of an authentication mechanism (e.g., ADSP,
>> SPF) where a DMARC policy is also discovered that specifies a
>> policy other than "none". {R7} To enable Domain Owners to receive
>> DMARC feedback without impacting existing mail processing,
>> discovered policies of "p=none" SHOULD NOT modify existing mail
>> disposition processing. Note that some Mail Receivers may reject
>> email based upon SPF policy mechanisms before email enters
>> DMARC-specific processing.
>
> I think the initial SHOULD represents a layering violation that is
> technically inappropriate from a design perspective, will
> substantially complicate implementation, and is not needed.  Details
> to follow.

FWIW, with respect to policy mechanisms, I think this is less a matter 
of "layering" than of "replacement". DMARC is asserting authority over 
the topic of policy, to the extent is has /overlap/ (rather than 
layering) with SPF or ADSP.

>
>>> Things that were written
>>>
>>> by people who already "know" what the spec is supposed to mean
>>> are often less clear to those outside the group. Until a broader
>>> group actually reviews it, there's no way to know.
>>
>> goes considerably beyond the original group, and yet there is so
>> far no concrete list of interesting changes being requested.
>
> The current implementers don't need the IETF spec.  The RFC should be
> oriented towards future implementers

Perhaps you missed the part about there now being a number of
implementers who were not part of the writing team?  Again, one would
have expected significant critical feedback from them, about problems
with the writing, over the last 1+ year.  (But then, the latest draft
does contain revisions...)

In any event, with an area director strongly against a "just improve 
the writing" work item, and no list of changes to be made to the base, 
there doesn't seem to be much to discuss about it.

> Absent a working group to actually do some independent review,
> there's no way of knowing what would come up.

You seem to think that it's ok to start a working group when there is no 
known work other than "review the document and figure out what might 
need doing".  By contrast, my long-standing model of a working group 
charter is that there is a clear set of problems to solve and/or 
enhancements to add and that this is clear /before/ chartering.

> Right, but the direction that the AD didn't like it was that the
> previous proposal constrained the working group too much.

He didn't seem to want any meaningful constraint.  While he, you, or 
whoever might feel that's fine, the folks currently holding the spec 
need more assurance of stability for the specification than that, given 
how recent the investment in it has been.

>  It seemed to me that there were
> a number of reasonable suggestions, including coming from the AD in
> question, that did a nice job of balancing the concerns of existing
> implementers without handcuffing the proposed working group.

That doesn't match my own reading of the thread(s).

>>> The one thing I think does need to be changed is the policy
>>> override approach.  Changing SPF policy based on DMARC is a
>>> layering violation at the very least.
...

 >    DMARC-compliant Mail Receivers SHOULD disregard any mail directive
...
 >    mechanisms before email enters DMARC-specific processing.
?

Where is there a demonstration of community support for changing this?

> In order to implement DMARC it's necessary for the component of a
> mail system that does SPF processing to have access to the 5322.From
> extracted from the body of the message (because of the SHOULD to skip
> SPF related policy decisions for domains that have a DMARC policy !=
> none and 5322.From provides the domain needed to determine if a DMARC
> policy is relevant for the message).
>
> Requiring data from the message body to do operations on the envelope
> is not a good idea.

Strictly speaking, it's not doing an operation /on/ the envelope, but in 
any event, the linkage to SPF's use of envelope information and DMARC's 
use of rfc5322.From information is rather basic to DMARC.

 From what I can tell, the change that you are concerned with, is 
DMARC's overriding SPF's /disposition/ mechanism, rather than its 
authentication mechanism.

In any event who supports the change besides you?  You've voiced it for 
awhile, so there ought to be some indication of support by now.

> The requirement to have access to the body of the message to do SPF
> checking in a DMARC environment is an architectural mess.

I guess I'm not seeing it as doing SPF checking.

> Yes, but not one that would require implementations to be changed to

...
> If you change a SHOULD requirement to a MAY requirement then nothing
> forces existing implementations to change.

You mean beyond reducing the likelihood that it will get implemented; 
are you asserting that this won't affect interoperability?

But again, this is frankly moot, absent a community desire to change the 
base specification.

>>> Fundamentally, rubber stamping the work of a private design team
>>> is not the IETF way.
>>
>> But since you are being pedagogical about how the IETF does
>> things, please note that working group charters are supposed to
>> specify the nature of the work to be done.  Working groups that
>> start without a sense of what problem they are trying to solve to
>> tend to have poor outcomes.  If you can specify the nature of the
>> technical, work to be done, sufficiently to garner support for it,
>> then it's certainly worth considering.
>
> I'm aware of one technical issue that I believe to be significant
> that needs to be addressed and wasn't addressed by the private design
> group.  Unless it's in scope for a working group to review the input
> of that work to the IETF, there is not likely to be the same level of
> review.

Scott, yes it's clear that you believe the issue is significant.  What's 
missing is an indication that the rest of the community wants a change.

> Additionally, I think it is very odd to submit the base spec as an
> independent submission and then form a working group to extend it.

Not "typical", no.  So?

> As I understand it, part of a working group effort is to get
> consensus around technical efforts. I'm not sure how you get
> consensus to extend something for which there is no IETF consensus.

The question will be consensus around the extensions.  Isn't modularity 
nice?

> I might even think that perhaps that the bit in RFC 4846 about the
> IESG review where it mentioned independent submissions shouldn't be
> an end run around the working group process might be relevant.

OK.  Please point to an existing IETF effort that this might be 
considered an end-run around.  That's what that reference was/is 
intended to mean.  And who else shares this view?

>  It
> also seems to me that if the DMARC base spec seeks to modify
> processing for IETF RFCs,

It doesn't.

> I think that if DMARC were entirely laid on top of SPF/DKIM/ADSP and
> there was not also a parallel proposal for an IETF working group to
> extend DMARC, then independent submission would not be inappropriate,

So, you think that ARP was inappropriate to have as an IETF effort, 
given that essentially all of the media specifications over which it 
operates -- that is, which it "extends" -- are outside of the IETF?

d/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Apr 2013 01:34:44 +0100

> how recent the investment in it has been.

I guess I'm the "he" above.

I've no idea what Dave means by "meaningful constraint." (That may
be just down to misinterpretations though. Hard to tell.)

I continue to argue for the same handling that the IETF used
for DKIM and XMPP. That seems to have worked well twice. I'm
quite surprised the DMARC group seem so much more concerned
about stupid changes than either the XMPP or DKIM folk, esp
since there seems to be quite an overlap between the DKIM
and DMARC groups. (Please do correct me if I'm wrong about
that overlap; its quite possible.)

I had a real problem with the previous proposed charter. I'm
not sure yet if I do with this one (while still preferring
doing what we did with DKIM/XMPP.) In order to know if I've a
problem with this one, I think I need to read the "base" spec
(which I've yet to do) because the current proposal seems to
be to have the ISE and chartering processes run in parallel
(which I find very odd). I suspect its very likely I will have
a problem with that, unless the ISE RFC has issued before the
IETF WG chartering process starts. (Only then can IETF folk
decide if they're ok with a new WG, since only then will the
ISE RFC text be final; but there is a chance that the "base"
spec is so good that its obvious, so I will read it first.)

And just in case that previous paragraph was confusing:

I continue to argue for the same handling that the IETF used
for DKIM and XMPP:-)

S.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 15 Apr 2013 21:35:37 -0400

On Monday, April 15, 2013 05:15:32 PM Dave Crocker wrote:
> > Here's the current, relevant snippet from the draft submitted to the
> > 
> > IETF:

I'll let Stephen speak for his own opinion on the chartering constraint issue.  
In my opinion, there's a reasonable way to write a charter that allows 
meaningful discussion and consideration of the current design, but that 
provides appropriate constraint on trivial changes.

As for the current issue I have with the design, I haven't particularly 
attempted to gather a constituency for it.  It was my impression from when we 
discussed it almost a year ago there would be an eventual IETF working group 
to work through this and any other issues people found.

I think that if a draft is submitted as a candidate working group work item 
and the sponsors don't like the result of the chartering discussion and that 
draft is suddenly an independent submission, that's pretty well, by definition, 
an end around the working group process.

2119 SHOULD words about how to change SPF and DKIM/ADSP processing are 
certainly modifying the intent of IETF RFCs.  Once again, it's pretty 
obviously the case and the only reason to avoid accepting it is to have a safe 
dodge of the ISE path to avoid an IETF working group and some need to get 
consensus outside of the private design group.

I keep hearing the IETF is about getting technology right and not about votes 
or who people work for.  The current design is wrong and in a way that it 
doesn't need to be wrong because all domains that don't want mail rejected on 
the basis of SPF or DKIM/ADSP need to do is publish policy records that say 
that.  DMARC trying to replace that existing functionality is utterly 
unnecessary.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Apr 2013 20:36:20 -0700

> an end around the working group process.

That's the same as saying that when one starts a negotiation, one is 
obligated to make a contract.

The initial chartering process is a negotiation between those bringing 
the work into the IETF and the IETF community.  Either side is free to 
agree or disagree with whatever terms they wish.

And free to walk away when there is not a sufficient meeting of the 
minds doing the negotiating.

The IETF does not have a 'right' to the work that is brought to it.

The ISE mechanism is for stuff that is relevant to the community, but 
isn't going through IETF or IRTF processing.  As a body of documents, 
the RFC series is larger than the IETF.

Work that is brought to the IETF has different levels of completeness 
and maturity, and different timings for having achieved those levels.

When the IETF charters a group and includes existing material, the 
charter can cast the role of that material in very different ways:

      It can treat it as nor more than a set of ideas, to be used or 
ignored;

      It can treat it as a basic design, with all of the actual details 
still fluid;

      It can treat it as a rough draft, to be massively revised;

      It can treat it as a solid specification that merely needs review, 
refinement and maybe enhancement;

      It can treat it as a deployed technology that should try to 
protect its installed base, but will tolerate some disruption;

      It can treat it as a deployed technology that /must/ protect its 
installed base and must ensure that core interoperability is retained 
with that installed base.

No doubt there are some other variations I've missed, but I hope this is 
enough to make clear that the choice of language in a working group 
charter, to constrain or not constrain the working group can make an 
enormous difference.

Equally, those bringing technology to the IETF do so at different points 
in the maturity of their work.  Any of the above might make sense, 
depending upon that maturity, the extent of deployment, and the timing 
of the investment made by the installed base.

When technology is brand new, with at most some prototypes done as 
proofs of concept, then significant changes to the spec won't 
necessarily add much to the development cost.  On the other extreme, a 
mature, deployed market can be almost cavalier about the freedom of a 
working group charter, because a working group that gets silly can be 
ignored: that is, the installed base is sufficiently well-established 
and unified in what it will accept, so that it's leverage is clear.

However, immediately after the development investment is made -- and 
especially when there has been considerable initial deployment, but 
still room for quite a bit more -- the installed and potential base will 
not take kindly to disruptive standards work; in fact such work can 
seriously damage adoption.

DKIM had almost no deployed base.  Jabber had quite a bit of deployed 
and mature base.

DMARC has a very large, newly-deployed base that just made the 
investment.  Making any changes that render the base not fully 
interoperable will a) piss of the folk who just made the investment, and 
b) possibly sour the folk considering deployment.  It typically at least 
causes the potential adopters to delay, sometime for years.

The charter that was originally submitted was tuned to the reality of 
DMARC's maturity and deployment.  Since that caused so much heartache to 
a few folk, the new draft charter removes the base spec from the current 
equation.  When deployment settles down and initial investment costs 
have been recovered, it will make sense to review the status of the base 
specification.

d/

ps.  I'm merely speaking for myself, of course, and not on behalf of the 
DMARC consortium.
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 15 Apr 2013 23:58:20 -0400

On Monday, April 15, 2013 08:36:20 PM Dave Crocker wrote:
> > and the sponsors don't like the result of the chartering discussion and
> > that draft is suddenly an independent submission, that's pretty well, by
> > definition, an end around the working group process.
> 

In this case it's more like announcing a lockout when the initial offer from 
management isn't accepted without modification by the union rather than 
determining a meeting of the minds cannot be achieved after good faith 
negotiations.

1.  How about this?
2.  Not quite, here are some alternatives we could discuss.
1.  I quit.

that's hardly a negotiation.

Your argument against a working group is that it will be hard to get people 
who have adopted DMARC already to implement interoperability improvements 
because they just implemented it.  Are you suggesting that it will be easier, 
later, when there is more deployment and the current pattern is better 
established?

Scott K

---

From: t.petch <[email-masked]>
Date: Tue, 16 Apr 2013 09:24:30 +0100

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "Scott Kitterman" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 16, 2013 4:36 AM
> the RFC series is larger than the IETF.

There is also the option of documenting existing practice, either via
the ISE or as an Individual submission, as an Informational RFC, with an
IETF Working Group later producing a Standards Track series of RFC of an
evolving specification.  (I have seen two examples of this).

Tom Petch

---

From: Dave Crocker <[email-masked]>
Date: Tue, 16 Apr 2013 07:47:05 -0700

> evolving specification.  (I have seen two examples of this).

Right.  I was focused only on documents being brought into a wg, but it 
probably helps to be more complete and cite the (not all that uncommon) 
path of starting with an Independent RFC that is informational.

d/

---

From: "J. Trent Adams" <[email-masked]>
Date: Tue, 16 Apr 2013 09:23:18 -0600

> later, when there is more deployment and the current pattern is better 

Yes, in this case it's likely that will occur. I can't speak to
everyone's development pipeline, of course, but in my experience
moderate to large enterprises require months and years of planning. The
most reasonable architects I've known include upgrade paths during
initial planning which address exactly what I think you're describing.
They'll be planning their solution based on current knowledge (ie the
existing spec) with a mind toward something like a two-year upgrade to
whatever the extensions (or possible revision) may be.

Another way to look at it is that since there's real value seen in
deployment today, there's a counter-incentive to wait an indeterminate
time for a possible revision. Each day that passes is another day that
customers are being phished... and, sadly, each phishing attack is yet
another opportunity for a cascading set of casualties (think: spear
phishing a whale).

I'm pretty sure we all agree that perfection can be the enemy of the
good. Getting a stable, useful, though possibly sub-perfect, solution
running is a reasonable path toward iterative improvement. Yes, it'll
take time to correct the ship under full sail, but it's possible (and
likely).

I'm all for learning as we go. Let's buckle down, explore some of the
key focus areas identified as possible (non-disruptive) extensions for
now and see how they play. Through that journey we will also learn what
needs to be done to improve the base and be the stronger for it.

Hoping for a brighter future,
Trent

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams

---

From: Dave Crocker <[email-masked]>
Date: Tue, 16 Apr 2013 08:37:10 -0700

...
> that's hardly a negotiation.

1. The exchange was more elaborate than that, including clarification 
for the reasons of the charter draft(s) that have been offered.  In 
addition, please note that the counter-proposal has not justified its 
position and, in fact, has been offered with complete rigidity, up to 
today, and hasn't responded to the concerns raised with it.

2. The lockout imagine is striking and entirely inapplicable, since 
there is no pre-existing relationship, nevermind an employer/employee one.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 16 Apr 2013 21:20:23 -0400

On Tuesday, April 16, 2013 09:23:18 AM J. Trent Adams wrote:
> > In this case it's more like announcing a lockout when the initial offer
> > from management isn't accepted without modification by the union rather
> > than determining a meeting of the minds cannot be achieved after good
> > faith negotiations.
> > 
> > 1.  How about this?
> > because they just implemented it.  Are you suggesting that it will be
> > easier, later, when there is more deployment and the current pattern is
> > better established?
> 

If what you have now on dmarc.org addresses the current need, why involve the 
IETF at all?  It seems to me that having any DMARC working group at all would 
have the kind of chilling effect you're concerned about.  I doubt that many 
outsiders would have their concerns assuaged by tight charter language.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 16 Apr 2013 21:23:12 -0400

> there is no pre-existing relationship, nevermind an employer/employee one.
Right.  It's an analogy and like all analogy is imperfect.  The part that's 
relevant is claiming a meeting of the minds is impossible without any serious 
effort to try (that's my assessment of the public discussion on the topic).

Also imperfect, but perhaps less orthogonal might be the analogy of the kid 
that shows up at the playground with a cool new toy and stomps off and goes 
home when the other kids won't play with the toy precisely according to his 
rules.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Apr 2013 09:12:19 -0700

On 4/16/2013 6:23 PM, Scott Kitterman wrote:
>> 1. The exchange was more elaborate than that,
...
> Right.  It's an analogy and like all analogy is imperfect.

Scott,

An analogy is supposed to demonstrate core properties that match the 

> home when the other kids won't play with the toy precisely according to his

entirely misses the point of what is currently happening.

The current exchange has had more of the flavor of:

    A:    How about X.
    B&C:  That's unacceptable, so do alternatives Y or Z.
    A:    Here are the reasons those alternatives don't match the
          current situation and here are the distinctive characteristics
          of the current situation.
    B&C:  Do Y or Z
    {rinse repeat}
    A:    OK, how about A.
    B&C:  Do Y or Z

After some iterations in this model, it become clear that the 
negotiation isn't a negotiation.

Until you and Stephen engage in discussing the substance of the 
responses you've been getting, there isn't a meaningful discussion 
happening.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 18 Apr 2013 14:53:53 -0400

> responses you've been getting, there isn't a meaningful discussion

OK.  It seemed to me that in your analogy is was more like A saying "How about 
X" over and over.

Since you are a part of the DMARC development community, do you have a sense 
of if that group is willing to support a working group charter that allows for 
technical changes to be made in the protocol in the event significant technical 
issues are discovered?

Scott K

---

From: "J. Trent Adams" <[email-masked]>
Date: Thu, 18 Apr 2013 14:46:53 -0600

Scott -

> technical changes to be made in the protocol in the event significant technical 

If I'm not mistaken, I think that the proposed charter makes provision
for exactly that happening. If enough data points are gathered through
the work of the group, it can decide to re-charter and crack open the
spec itself. We'll just want to be sure that it's a data-driven decision
rather than something more theoretical.

Does that hit close to what you're looking to achieve?

- Trent

-- 
J. Trent Adams

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 18 Apr 2013 16:50:50 -0400

On Thursday, April 18, 2013 02:46:53 PM J. Trent Adams wrote:
> > OK.  It seemed to me that in your analogy is was more like A saying "How
> > about X" over and over.
> > 
> > Since you are a part of the DMARC development community, do you have a
> > sense of if that group is willing to support a working group charter that
> > allows for technical changes to be made in the protocol in the event
> > significant technical issues are discovered?
> 

No.  The latest draft excludes such work from consideration without 
rechartering.  It pretty much the opposite of what I was looking to achieve.

Unless working on the base draft is part of the work of the working group, it 
won't happen.  Personally, I'm far more interested in the base spec than any 
extensions proposed so far.  I doubt I'd devote much time to the working group 
if chartered based on the current draft.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Apr 2013 14:03:37 -0700

On 4/18/2013 1:50 PM, Scott Kitterman wrote:
> won't happen.

Scott,

We've done multiple queries to the community, for a listing of work to 
be done.  There's currently no community desire to work on the base 
specification.

While you've made your own desire clear, there is no evidence of 
community support for the change you want.

It makes no sense to charter a working group to change a specification, 
when there is no community desire to change it.  Indeed, the IETF does 
not typically charter a group to do work when there is no support for 
doing the work and, in fact, no list of the work to be done.

If there is a serious problem discovered with the current base 
specification, the community will want it fixed.  At that point, getting 
rechartering is likely to be pretty easy, since it will have specific 
focus, rather than being open-ended.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 18 Apr 2013 17:09:43 -0400

On Thursday, April 18, 2013 02:03:37 PM Dave Crocker wrote:
> > Unless working on the base draft is part of the work of the working group,
> > it won't happen.
> 
> Scott,
> 

I think it's buggy in one way I've already described, but since it both 
doesn't affect existing IETF RFCs (and this is suitable for independent 
submission) and replaces the policy aspects of SPF and DKIM/ADSP (so it's not 
architecturally buggy), I'm sure it's fine.

Scott K