Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin

From: Franck Martin <[email-masked]>
Date: Mon, 1 Jul 2013 22:11:19 +0000

On Jun 30, 2013, at 3:14 PM, John Levine <[email-masked]> wrote:

>> And there have recently been some detail, independent reviews that
>> are prompted a document revision that will be issued within days.
> 
> While I don't doubt that the next version will be better, I think that
> the dmarc.org group needs to make up its mind and either get a
> reasonably chartered IETF WG that says no gratuitous changes to the
> bits, contribute all of the drafts to the WG, and take its chances. or
> else contribute none of them and just send them in via the independent
> stream.
> 
> I understand why you might want to tell the IETF that it can only
> change the minor documents, not the major one, but I don't see why the
> IETF would be interested.
> 

This is my take on the process so far.

The spec has been handed over to IETF already. IETF can do what it likes with it. So I don't think the DMARC.org group worries (much) about what can be changed or not.

The question is: is there sufficiently enough work to be done in the current spec (besides editorial) that warrants an IETF WG to work on the spec?

So far the answer to that question is no. The reason: even has a non IETF WG, the DMARC.org group has been listening to all comments and the deployment experience has shown the mechanism is robust across multiple segments.

So the logic conclusion: the spec needs to be AD sponsored to be on the standard track.

But I realize this will not stop conspiracy theories.

If I'm mistaken, please review the spec and answer the question with specifics.

---

From: "John R Levine" <[email-masked]>
Date: 1 Jul 2013 18:58:51 -0400

> The spec has been handed over to IETF already. IETF can do what it likes 
> with it. So I don't think the DMARC.org group worries (much) about what 
> can be changed or not.

The draft-kucherawy-dmarc-base-00 document has a license that, as I read 
it, is not compatible with a standards track document.  It wouldn't be 
hard to fix, but it needs fixing.

> The question is: is there sufficiently enough work to be done in the 
> current spec (besides editorial) that warrants an IETF WG to work on the
> spec?

That's not the question I see.  It's whether this is an IETF effort or a 
dmarc.org effort.  Maybe the base document will be all done by the time 
the WG is spun up, maybe not, but that should be the WG's decision.  I 
think everyone agrees that the BCP is a long way from being publishable, 
so there's certainly work there.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Jul 2013 16:12:00 -0700

> else contribute none of them and just send them in via the independent

John,

Your premise is that something problematic and possibly wrong is being 
done.  It isn't.

The base specification is being submitted through the 'individual 
submission' path within the IETF stream.  We have a sponsoring AD and we 
are following his guidance for this.

An initial version of the draft was posted as an I-D.  The sponsoring AD 
has pressed for a number of reviews to be done.  An initial set were 
done and came back calling for some significant editorial changes, but 
no technical changes, essentially to make the document better to read.

Let me repeat:  better writing; no technical changes.

That seemed like an obviously good suggestion, so we are responding to 
it.  Rather than impose the original I-D on further reviewers, we 
decided to fold in their guidance now, with initial update, so that 
further reviewers can benefit from the improvements.

A working group is for technical work.  We've solicited suggestions for 
incremental technical work at least twice in two forums and there has 
been no constituency developed for any near-term work.  If you know of 
work to be done and can develop community support for it, please, 
please, please document it.

At that point, it will be worth considering working group chartering for 
technical effort on the base dmarc spec.  Absent that, it isn't.

As for the 'status' of the document, we are targeting a standards track 
RFC through the IETF stream.  The copyright choices for that are quite 
constrained.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 2 Jul 2013 01:33:02 -0000

>please, please document it.

If reviewing the spec is off the table, I don't see any work other
than cleaning up the BCP.

Since the dmarc.org group seems to have a working process to write
drafts adequate to publish using member employees and consultants, I
see no reason for the IETF to invest volunteer cycles on it.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Jul 2013 19:22:13 -0700

On 7/1/2013 6:33 PM, John Levine wrote:
> If reviewing the spec is off the table,

That's not what I said.

 > I don't see any work other

If you mean the "Using" draft, it needs considerably more than cleaning up.

> see no reason for the IETF to invest volunteer cycles on it.

Sorry you are not a fan of the individual submission path for the IETF 
stream.

Oh, wait:

    RFC 6713
    RFC 6143
    RFC 5518

These appear to be RFCs you authored that were through the IETF's 
individual submission path and RFC 5518 (VBR) appears to be Proposed 
Standard.

So now I'm confused about what your objection is.

d/

---

From: "John R Levine" <[email-masked]>
Date: 1 Jul 2013 22:27:58 -0400

> Sorry you are not a fan of the individual submission path for the IETF 

You have it backwards.  I think the individual path is just dandy for 
competent documents written elsewhere.

My point is that since dmarc.org can do this stuff, why should the IETF 
spend volunteer time on a WG?

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 01 Jul 2013 22:40:59 -0400

> Let me repeat:  better writing; no technical changes.

I disagree.  I've been saying repeatedly that I think that the policy 
overrides are a layering violation that should be removed.  They are bad 
design.

I'll add to that that having watched senders try to interpret XML reports they 
receive from different providers and understand the subtleties between them 
that while the mechanics of the XML schema are there, the semantics are not 
clear enough to provide for interoperable implementations.  Even among 
implementers who have worked together in dmarc.org to develop the schema, 
there are inconsistencies.

I don't think there is anything in the two issues about that would force 
existing implementers to make changes, but I think that they are not purely 
editorial either.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Jul 2013 19:46:54 -0700

> overrides are a layering violation that should be removed.  They are bad

Yes you have.

And where is the community constituency that supports that view?

> there are inconsistencies.

Not sure what you are suggesting, as technical work, for the reporting 
mechanism.  I also missed the demonstration of community interest in 
those changes, ideally on this list.

> existing implementers to make changes, but I think that they are not purely

Sorry for my confusion, but I don't know how to classify the changes 
that you seem to be calling for.

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Jul 2013 19:49:00 -0700

On 7/1/2013 7:27 PM, John R Levine wrote:
> I think the individual path is just dandy for

Like Domain Assurance Council did for VBR?

> spend volunteer time on a WG?

Why was volunteer time reasonable for VBR but not now for DMARC?

d/

---

From: "John R Levine" <[email-masked]>
Date: 1 Jul 2013 23:30:43 -0400

We do seem to be suffering from a failure to communicate, don't we?

According to the subject lines of the messages we've been exchanging, 
we're talking about a BoF for DMARC.  I hope we agree that the reason to 
have a BoF is to see if a topic merits a working group.

According to what you've said, the DMARC technical draft is good enough 
that you'll send it in as an independent submission, no WG involved. 
Franck says that if people have comments on it, they can send them to the 
dmarc.org list and that group will listen, which matches my experience.

The only other document I'm aware of is the BCP draft.  That draft is a 
mess, but the dmarc.org group who wrote the technical draft seems entirely 
able to fix it into something reasonable and send it in as another 
independent submission, leaving nothing for a WG to do.

Perhaps my reference to volunteer time was confusing.  I realize that an 
independent submission takes some time from the AD*, IESG*, and whoever 
looks at it in last call, but a WG is a lot more with chairs, members, 
document editors, and whoever.  It's the latter group who don't need to 
spend time on DMARC.

Unless I'm missing something important here, it seems so obvious that 
DMARC doesn't need a WG that perhaps we should can the BoF and give the 
slot back, since I gather there's a lot of other groups who could use it.

Regards,

* - who are stuck either way

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 01 Jul 2013 23:41:24 -0400

> And where is the community constituency that supports that view?

How many experts on the policy mechanism DMARC wants to mess with are involved 
in the discussion?  So far, DMARC is pretty much a self-licking ice cream 
cone.  To claim the lack of broad community support for a particular change is 
a reason not to seek broad community review seems like a bit of a catch 22.

> > I'll add to that that having watched senders try to interpret XML reports
> > they receive from different providers and understand the subtleties
> > between them that while the mechanics of the XML schema are there, the
> > semantics are not clear enough to provide for interoperable
> > implementations.  Even among implementers who have worked together in
> > dmarc.org to develop the schema, there are inconsistencies.
> 

Since this is the first time I've mentioned this particular point, it's not 
surprising there isn't much feedback on it.  You don't ask for anything here 
that wouldn't require time travel.

> that you seem to be calling for.

I'm' sorry too.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 01 Jul 2013 23:45:34 -0400

On Monday, July 01, 2013 10:11:19 PM Franck Martin wrote:
> with it. So I don't think the DMARC.org group worries (much) about what can
> be changed or not.
> 
> The question is: is there sufficiently enough work to be done in the current
> spec (besides editorial) that warrants an IETF WG to work on the spec?
> 
> So far the answer to that question is no. The reason: even has a non IETF
> WG, the DMARC.org group has been listening to all comments and the
> deployment experience has shown the mechanism is robust across multiple
> segments.
> 

Personally, I'm getting tired of investing time in it.  It seems like the only 
response to comments amounts to "La La La La, I can't hear you".

Of course I've no idea what you DMARC folks are doing in private, but that's 
part of the problem.  There's no transparency and it seems so far not a lot of 
openness to outside input.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Jul 2013 21:15:57 -0700

> a reason not to seek broad community review seems like a bit of a catch 22.

Scott,

This list has been available for some time, to discuss the dmarc spec, 
the Using draft, the draft charter and the planned BOF.

Note that your opening text here was "I've been saying repeatedly".  My 
query about community support for your concerns was based on that 
reference.

In any event, you are indicating that you have concerns over the 
specifications.  That's fine, of course, but there needs to be some 
community resonance with that concern, to justify opening up the spec 
and pursuing it.  That's merely standard IETF process.

Again:  if you want folks on this list to press for something to be 
done, please recruit folks on this list to support its being done.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 02 Jul 2013 00:20:57 -0400

On Monday, July 01, 2013 09:15:57 PM Dave Crocker wrote:
> > How many experts on the policy mechanism DMARC wants to mess with are
> > involved in the discussion?  So far, DMARC is pretty much a self-licking
> > ice cream cone.  To claim the lack of broad community support for a
> > particular change is a reason not to seek broad community review seems
> > like a bit of a catch 22.
> Scott,
> 

It's a bit difficult to have a conversation about things that are being decided 
in private, particularly when those in the private club dismiss external 
input.  I guess I've misunderstood the IETF.  I had this crazy notion it was 
about getting the proper technical solution, not collecting votes for a 
position.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Jul 2013 21:26:56 -0700

> We do seem to be suffering from a failure to communicate, don't we?

Evidently there is, since it now appears that your concerns are actually 
with the draft charter.

The charter proposes some stuff.  Perhaps you can comment in terms of 
what is missing or inappropriate about it?

So far, the gist of your concern seems to be that since a private group 
has already been doing some productive work on a topic, there's no need 
(never any need?) to have the IETF work on the topic?  But perhaps I've 
misunderstood that.

The fact that a group did some stuff does not automatically make it 
inappropriate to consider further work to be done on the topic in the 
IETF.  Ultimately, dmarc.org would like to disband.  Getting the spec 
published through an established IETF vetting process and getting a 
usage BCP developed are not all that unusual.  (The draft charter cites 
more than that.)

At the least, the BCP is real work.  Your classing it as a real mess 
suggests that you agree.

I assume you didn't object to DKIM following a broadly similar path. 
Since it was in a different place in development and deployment, it 
happened to be more amenable to protocol development in an IETF working 
group.  But there were also the other docs produced.  Their development 
didn't depend on first having an IETF working group develop the base 
specification, unless there's some unwritten rule I've missed.

> that you'll send it in as an independent submission, no WG involved.

And since I keep hassling the dmarc folk about this finicky point, I'll 
stay consistent and note:  Individual submission on the IETF stream, not 
Independent stream.

> Franck says that if people have comments on it, they can send them to
> the dmarc.org list and that group will listen, which matches my experience.

My own recommendation is to post comments on this list, not the 
dmarc.org list, so that they are within the IETF sphere.

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Jul 2013 21:28:25 -0700

> about getting the proper technical solution, not collecting votes for a

The concerns you have are not being decided in private.

Raise them on this list.  Discuss them on this list.  Recruit support 
for them on this list.

I'm quite certain that IETF management will pay attention to the support 
you develop for work to be done.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 1 Jul 2013 21:56:03 -0700

> about getting the proper technical solution, not collecting votes for a
There are a lot of assumptions being made here.  Let me put some of them to
rest:

I'm currently volunteering as the lead editor on this document.  That the
concerns expressed on this list by yourself, Eliot, SM, and anyone else
have not immediately resulted in a new draft being issued addressing them
is not automatically evidence of cabal-like behavior or intent by the
community that created the work.  I/we simply haven't had the time to go
through the motions required to crank out a new version, especially given
the nature and volume of some of the feedback requiring a lot of editing
work on the XML source.  I apologize unreservedly that this has ruffled
feathers, but as John points out, I'm a volunteer like the rest of you with
other obligations, and in the past few weeks this has simply not been at
the top of my priority list.

And even if a revision appears that doesn't address your pet rock, it's
entirely (perhaps even likely) that it got missed in error, not because it
was rejected.  (See above about priorities.)

As an admitted "insider" here, please invest whatever trust you have in my
integrity that not one iota of feedback has been discarded out of hand by
anyone.  We are not so stupid as to think we'd get away with it, nor do we
think the IETF is so stupid as to try, nor do we think anyone would find
the IETF rubber stamping something like this onto the standards track to be
anything close to palatable to the community.  A number of dialogs have
taken place to get us here, which involve compromise and negotiation.  I
believe there's far more cooperation going on here than people are allowing
for in these arguments.

I'm pleased to hear John's experience of the DMARC people to date is that
we do listen to feedback.  I believe we've gone to great lengths to be
accessible, and I would also say, for example, that the community which
created the pre-IETF drafts of DKIM was far less open yet suffered far less
objection when it approached a BoF.  I'm sorry that your experience has not
been like John's, but that's not the result of secrecy or anything sinister.

What I think would be more productive here is discussion of what's in the
proposed charter.  I'm thinking about what's in RFC5434 because it's clear
to me, at least, that there are enough people who are interested in working
on this to justify at least having the BoF.  As Barry points out, the
outcome of that BoF will (hopefully) be a clear indication as to whether a
working group is appropriate.  I think it is, but I also think the
conversation about what the charter should be like is one we need to have.
That's brought us here.

John stated that if dmarc.org can do the editing and development it's done
so far, then dmarc.org can finish it independent of a working group.
That's certainly true, but by that reckoning a number of things now on the
standards track also shouldn't have bothered to come into the IETF.  A
large number, in fact.  I suggest, then, that DMARC is as legitimate a
candidate to bring in half-baked or even three-quarters-baked as all the
other things in the past that have fit that description.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 02 Jul 2013 01:24:44 -0400

On Monday, July 01, 2013 09:56:03 PM Murray S. Kucherawy wrote:
...
> conversation about what the charter should be like is one we need to have.
...

So far, in this thread the base spec has been ruled out and then possibly in 
for the BoF.

http://www.ietf.org/mail-archive/web/dmarc/current/msg00309.html

I think it's very difficult to have a conversation about what work needs to be 
done at this point because we don't know what the base spec looks like.  I 
think the last published version has some design issues that need to be 
addressed and it not nearly clear enough to support development of 
independent, interoperable implementations (including particularly the data 
exchange).  

I understand there's work in progress to improve that, but until we know what 
it looks like, how can we possibly have an opinion on if it's adequate or not?

To me, the entire question of a WG or not and if so, what it's scope should be 
turns on the question of if there's already a well developed specification that 
doesn't need further work.  So far, I haven't seen one.

I'm not arguing for conspiracies, just that for those of us on the outside of 
the group, we don't know what we don't know.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 2 Jul 2013 05:27:46 -0000

>proposed charter.

Replace the second and third paragraphs with:

 The working group will adopt draft-kucherawy-dmarc-base as an input
 document and any other drafts the the group deems relevant and useful,
 with the goal of publishing a standards track DMARC specification and
 posssibly other documents.  In view of the large base of running DMARC
 code, the group will avoid changes that would cause incompatible
 changes to bits on the wire.

Delete the 13th paragraph.  Delete discussions of mailing lists which are
a hopeless black hole.  Adjust the schedule to taste.

Alternatively, per my previous colloquy with Dave, delete text
starting with "Email abuse often ..." and ending with "... guide to
WGLC."

R's,
John

PS: For people who have lost track, the draft charter is here:
http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 1 Jul 2013 22:52:41 -0700

> it looks like, how can we possibly have an opinion on if it's adequate or

There's no requirement of which I'm aware that says the documents on the
table at a BoF have to be anything close to complete.  They merely have to
be a starting point for the conversation.  It could be that they need a ton
of work, and it could be that they don't.

It seems to me your concern is that there won't be any conversation at all;
meanwhile it's obvious to me just from a few reviews plus your feedback
that there will be at least some if not a lot of changes to the prose in
many places.

Personally, I think this can be done very reasonably without disturbing the
installed base much if at all.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 02 Jul 2013 02:03:37 -0400

> installed base much if at all.

I agree that it seems the needed changes are unlikely to affect the installed 
base.  My concern is that the plan appears to be an AD sponsored base 
specification with maybe a working group to address the BCP and potentially 
other things.  

To have a good understanding of if that's a reasonable plan, you need a base 
spec that's pretty ready to go.  If the draft charter is adjusted to take your 
document as an input to the WG and have the base spec as an output to the WG, 
then I entirely agree about the level of maturity required in the documents.  
I'm confident that whatever you produce would be quite suitable as the input to 
a WG effort.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Jul 2013 07:30:54 -0700

On 7/1/2013 10:24 PM, Scott Kitterman wrote:
> done at this point because we don't know what the base spec looks like.

Yes you do.

The changes being done are non-technical.  The technical details have 
been visible and stable for a long time.

You've also participated in other IETF group discussions during document 
development.  So the idea that a document is undergoing changes and yet 
is still being talked about is something you are familiar with.

> I

The clarity issue might well be a matter of writing quality, and that's 
what the current round of revisions is attempting to address.  "Design 
issues" sounds more technically substantive.  As has been said, no 
design changes are being made to the document in the current round.

Once again:  If you have technical concerns -- including design concerns 
-- please raise them here; pursue them here; resolve them here through 
group consensus.

> the group, we don't know what we don't know.

You don't know what editorial changes are in the midst of being made. 
That's typically true for working group documents, too, since most leave 
such things to the editor.

However you /do/ know all the technical details, because they have been 
public and stable for quite awhile.

d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Jul 2013 07:46:43 -0700

>   The working group will adopt draft-kucherawy-dmarc-base as an input

What is the work to be done on the base document?

Please provide substance rather than form.  The substance describes the 
work or the nature of the work with a sense of what is useful about the 
deliverable.

The charter of work for a working group is supposed to give a sense of 
the work.  While some charters do indeed seem to say "we'll take on the 
document and then figure out what we want to do with it" that is rarely 
a constructive model for getting anything useful published anytime soon.

d/

---

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Jul 2013 11:11:36 -0400

Scott, I'm clumping bits from a few of your messages in this thread
into one reply; I think it'll make it easier.

> overrides are a layering violation that should be removed.  They are bad

Repeatedly?  I've just re-read every message you've posted to this
mailing list, and I see none in which you've said this, none in which
you've done a review of the dmarc base spec document, and several in
which you've said that you're using dmarc and are supportive of it.

I'm sure you think there are things that should be changed.  The best
way to suggest that is to do a review of the document, to post it
here, and to be specific about what you want to see changed.

> existing implementers to make changes, but I think that they are not purely

Excellent; put an expansion of that into a review, making sure that
it's clear about what the problem is and what, specifically, you want
to change.

> response to comments amounts to "La La La La, I can't hear you".

This and statements like it don't seem to be fair: I see no evidence
that anyone is unwilling to listen to comments (from you or anyone
else).  Responses might disagree with you, and people might think that
changes you want made should not happen... but that's technical
disagreement, not refusal to listen.

In any case, I haven't see any real opportunity to discuss what issues
you might have with the dmarc protocol, because I haven't seen you lay
those issues out clearly so they can be discussed.  Please do that.

Really: please do that.  Please don't get tired; get specific.

> specification with maybe a working group to address the BCP and potentially

Whether the base spec is AD-sponsored or handled by a working group
isn't going to affect the quality or depth of review that I'm going to
insist on.  The dmarc spec will not become an IETF Standards Track
document without a good deal of thorough review, discussion and
changes where that's necessary, and significant support for putting it
on the Standards Track.

The path of AD sponsorship is happening because there was difficulty
in converging on a charter that included the base spec (see the
discussion on the apps-discuss list about that).  Such a working group
is still not out of the question, but the level of technical work that
appears to be needed for the base spec is very low -- that's what
makes it reasonable to AD-sponsor it if the community gets behind it
with review and discussion.

In this post: http://www.ietf.org/mail-archive/web/dmarc/current/msg00184.html
...you say this:

> I'm not certain what the best answer is, but I think that at least getting the
> spec to say you can publish p=none and not affect existing behavior is very
> important.  Unfortunately, there's no venue to discuss updating the base spec.

*This* is the venue to discuss updating the base spec.  Clearly, those
who have deployments of dmarc don't want to see changes that will
affect their deployments.  That said, there's no restriction on what
aspects of dmarc can be discussed on this list.  You want to propose
changes, do as I said above: post a review of the document and be
specific about what you want to see changed and why.  And then
participate in the discussion that ensues.  Scattered comments in
other threads that give very brief mention to issues you have are hard
to follow, hard to get into real discussion of, and hard for editors
to track.

Barry, Applications AD

---

From: "John Levine" <[email-masked]>
Date: 2 Jul 2013 15:31:38 -0000

>What is the work to be done on the base document?

I don't know, because nobody other than perhaps Murray knows what it
says.  Maybe the WG will look at it and say it's done, maybe they will
find problems like the ones Scott alluded to.

Telling us "the base document is all done, don't you worry your pretty
little heads about it" is just insulting.

Also, see the next message for more concrete comments on the current charter.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Jul 2013 09:19:05 -0700

On 7/2/2013 8:31 AM, John Levine wrote:
> says.

John,

That's not true and you know it's not true.

And the fact that it's not true has been explained repeatedly.

d/

---

From: "John Levine" <[email-masked]>
Date: 2 Jul 2013 18:51:13 -0000

>>What is the work to be done on the base document?

One final thought and then I'll stop: If you think that there is some
chance of making progress on the first four charter items, it seems
likely that the results of that progress would go into the base
document.

I suppose an alternative would be to send the base document through
separately, then after it's published charter dmarcbis that would
start with the RFC as an input, a highly compressed version of what
spfbis is doing, but that seems like a lot of extra work for no
benefit.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Jul 2013 12:12:53 -0700

> spfbis is doing, but that seems like a lot of extra work for no

Your presumption is that it's necessary to make changes to the base 
document for these enhancements.  Mine is that it isn't.

So we don't need to wait.  We can proceed with the listed tasks now. If 
we find that we really do need to wait... we can.

Your approach imposes potentially unnecessary delay.  Mine doesn't.

d/

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 02 Jul 2013 23:29:49 +0200

On 07/02/2013 07:27 AM, John Levine wrote:
>   posssibly other documents.

+1

> In view of the large base of running DMARC

-1

Granted, the installed base is large, but let's not ignore the other 40 
percent of the Internet. IETF standards are standards for the _entire_ 
Internet community, not just ten or twenty of the largest companies in a 
specific area. The WG should not be bound by 'bits on the wire' in their 
review and possible comments on the standard. Otherwise the IETF is to a 
large extent degraded to the 'rubber stamp business' Scott mentioned.

Don't get me wrong: the outcome of the discussions may well be that 
nothing will change on the wire and that'd be fine. But including this 
in the Charter as a precondition for the work to be done is wrong in my 
opinion.

> Delete the 13th paragraph.

Not sure which one is that? Just to make sure we're on the same page: 
we're talking about 
http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC, isn't it?

> Delete discussions of mailing lists which are

+1

/rolf

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Jul 2013 19:55:41 -0700

>>   posssibly other documents.

What technical work do you want done?  Why?  Who else do you believe 
wants it?

> percent of the Internet.

Presumably you have some empirical data that supports claims that that 
other 40% wants technical changes to the specification?

d/

---

From: Matt Simerson <[email-masked]>
Date: Tue, 2 Jul 2013 21:50:09 -0700

On Jul 2, 2013, at 2:29 PM, "Rolf E. Sonneveld" <[email-masked]> wrote:

> Granted, the installed base is large, but let's not ignore the other 40 percent of the Internet. IETF standards are standards for the _entire_ Internet community, not just ten or twenty of the largest companies in a specific area. The WG should not be bound by 'bits on the wire' in their review and possible comments on the standard. Otherwise the IETF is to a large extent degraded to the 'rubber stamp business' Scott mentioned.
> 
> Don't get me wrong: the outcome of the discussions may well be that nothing will change on the wire and that'd be fine. But including this in the Charter as a precondition for the work to be done is wrong in my opinion.

+1 to Rolf's -1. 

I'm happy to see DMARC moving towards becoming a standard. Validation of incoming messages is a great feature. Reporting is more timely and structured than bounce messages. But for the vast majority of mail senders, DMARC is close to useless because of the forwarder / mailing list issue. 

	"DMARC policies are not appropriate for domains with users who send mail through mailing lists" --John R Levine

	"SMTP refusal to an unmapped-but-reliable forwarder is likely to cause list unsubscription." --Roland Turner

The mailing list issue is intractable and also a huge implementation barrier that is barely documented. For legit domain owners (ie, not abusers) that wish to use DMARC to curtail phishing from their domains, they will need to choose between losing legit mail (DMARC + mailing lists) or not losing legit mail (no DMARC). 

Most of the broader internet community does not have the resources to "map the exit IP addresses of well-behaved forwarders and ignore DMARC results for messages that come from those addresses."  As such, many domain owners will deploy DMARC, lose valid mail, and then reject the technology.

While it may be kinda sorta true that DMARC "protects 60% of global consumer mailboxes," it seems to be  marketing puffery. While 60% of global mailboxes may have some form of DMARC validation, the number of legit domains that do and potentially *can* deploy DMARC records is absurdly low. 

Other minor Issues such as report loops (DMARC reporters reporting each others DMARC reports to each other ad infinitum) are minor and have simple (but not yet documented) workarounds but could also be addressed technically, rather than requiring workaround documentation.

Matt

---

From: SM <[email-masked]>
Date: Sat, 13 Jul 2013 14:32:47 -0700

>a hopeless black hole.  Adjust the schedule to taste.

I don't have a strong opinion about whether the future working group 
should or should not work on a draft about mailing lists.  A small 
number of people who have participated in IETF discussions about 
mailing lists are aware that it is a hopeless case.  Who knows, maybe 
this group will succeed where everyone else failed.

Regards,
-sm

---

From: "J. Trent Adams" <[email-masked]>
Date: Tue, 16 Jul 2013 09:39:20 -0600

Thanks, everyone, for their input on this thread (and to John for the
pointer how to get back to land when I blundered into the wrong stream).
Editing the proposed charter is a lot easier with this feedback.

>From what I can tell, the most important question needing to be answered
is whether or not revising the base DMARC specification is within scope
of the proposed work group. Following Russ's guidance, it seems that we
should start from the assumption that it's not in scope for now given
the fact that it's being sponsored by an AD as an Individual Submission.

Regardless of whether that's the right path, or not, let's explore it as
an option and see how the rest of the items identified in the proposed
charter play out. Then we can leverage the outcome of the conversation
to potentially revisit the fate of the base specification itself.

Given that guidance, here're the most obvious (and noncontroversial?)
items needing to be done to shore up the proposed charter:

* Correct the text regarding the current path of the specification.
* Tone down the "marketing puffery".
* Clarify how to address "backward compatibility" with the installed base.

I've already updated the description of the current path of the base
specification from "Independent Submission" to "Individual Submission",
so that's one down. I'll pull out my red pen on the other two topics and
see if I can make them more reasonable.

Skipping ahead. . . here're the items that have previously been proposed
as worth exploring in the setting of an IETF work group:

-----
* a mechanism for determining the organizational domain name based on an
arbitrary fully-qualified hostname
-----

If I'm not mistaken, the Apps Area WG has already expressed an interest
in this work. In that case, I believe that this WG would only need to
track that effort and ensure that its work addresses the use cases
required to support DMARC.

QUESTION: Given that it's an important topic, and there's no guarantee
that the other effort will result in an applicable solution, would it
still be reasonable to include a mention of this as worth exploration?
If so, it'd probably make sense to reference the other work as a
starting point to clarify we're not planning to spin up a competing
solution.

-----
* a mechanism for detecting abuse involving the <display-name> portion
of the RFC5322.From field
-----

This is an interesting item in that there have been some proposals from
contributors to the base DMARC specification to address this. The
proposals, as you can see, didn't make it through to a consensus and it
was suggested that they be brought to the broader community for
consideration. It's highly likely that through the WG process we're able
to identify a means by which this issue can be addressed.

QUESTION: Does it make sense for this proposed WG to explore how the
base specification can be extended to apply the same level of
"identifier alignment" to the <display-name> as is helping defend the
<address-spec>?

-----
* a mechanism for mitigating the effect of failures of DMARC policy when
a message transits a mailing list
-----

I recognize that there's definitely a counter-pressure against including
this topic as it seems to be a potentially quixotic quest. That being
said, even if we don't find the perfect solution, it does seem
reasonable to believe there is a way to provide something more than
nothing that does help in some meaningful way. I'm not presupposing a
solution, just that there have been a few possible options discussed at
the edges which are likely to be worth more rigorous exploration.

QUESTION: Is there value in a WG such as this exploring possible
solutions to this issue and developing guidance that would potentially
help improve the utility of the base DMARC specification?

-----
* support for the notion of transitive trust (i.e., "host X trusted the
sender of this message, and I trust X, so you should too")
-----

I see this as similar to the above, but potentially more broadly
applicable. One tweak I'd offer would be to replace ", so you should
too" with something like ", so you could choose to as well".

QUESTION: Is there value in a WG such as this exploring possible
solutions to this issue and developing guidance that would potentially
help improve the utility of the base DMARC specification?

-----
* more robust transport of reports
-----

After over a year of deployment, and the rise in support services
handling reports, many folks have suggested that it would be worth
exploring how to offer additional optional means of transport for
reports. The base DMARC specification provides for this, but it is an
area that was left to be extended by a group such as this.

QUESTION: Is this an area of exploration that is of enough interest to
include in the charter for this proposed work group?

Beyond those, the topics in the proposed "Using DMARC" document have
already proven useful in clarifying some options that aren't typically
included in a base specification. For example, here a few items that may
benefit from being specifically called out in the charter as worth
exploring:

* Identifier alignment configuration options
* Implementation decisions regarding "pct"
* Determining effective RUA sending frequency
* Leveraging policy caching
* Various options for integrating within an existing flow
* Defining a useful, common set of RUA reporting options
* When and how to use local policy override options

QUESTION: Do any items on this list seem to be worth specifically adding
to the proposed charter as examples of the type of work that would be
useful?

Finally, this list of potential work items was developed a while ago,
and it's likely additional possible areas of exploration have surfaced
since then. Are there any other substantive items that would be worth
adding to the list? Keeping in mind, of course, that our first cut will
be to assume that the base specification isn't in scope for now.

Once the dust settles a bit around these items, I'll take another whack
at the charter text to at least get it stable for now. Then we can
bubble up the bigger question and see if we can tackle that given the
input I've seen recently on other threads.

Thanks again,
Trent

On 7/2/13 10:50 PM, Matt Simerson wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

-- 
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 Jul 2013 08:50:05 -0700

> * Tone down the "marketing puffery".

While I think the existing text isn't all that puffed-up, something 
along the lines of what it says is still helpful to include.

The key point is that the existing specification has a sufficiently 
large installed base to warrant considerable care in making changes that 
would disrupt it.

> * Clarify how to address "backward compatibility" with the installed base.

Perhaps:

      In order to protect the installed base, any changes to operational 
practice or bits over the wire need to be incremental and optional. 
That is, they need to be added as extensions to existing practice, 
rather than make changes to it.  This permits unmodified software and 
operations to continue to interoperate with those that are upgraded.

> still be reasonable to include a mention of this as worth exploration?

Not in a charter, unless the wg is going to explore it, which it won't.

> starting point to clarify we're not planning to spin up a competing

In formal IETF terms, other work isn't real yet.  So the reference would 
be to something not yet having any substance.

> help improve the utility of the base DMARC specification?

If the wg handles this carefully and pragmatically, there might be some 
benefit in at least documenting the topic, in terms of concerns and 
choices.  I believe there isn't an IETF published paper in this realm, 
in spite of the issue appearing regularly.

It might also chart out one or two pragmatic paths for change that are 
worth exploring.  As such, this would be a non-normative discussion 
paper, rather than a specification.

d/

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 16 Jul 2013 16:22:09 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of J. Trent Adams
> Sent: Tuesday, July 16, 2013 11:39 AM
> To: [email-masked]
> Subject: Re: [dmarc-ietf] Charter improvements
> 
> 
> Thanks, everyone, for their input on this thread (and to John for the pointer
> how to get back to land when I blundered into the wrong stream).
> From what I can tell, the most important question needing to be answered is
> whether or not revising the base DMARC specification is within scope of the
> proposed work group. Following Russ's guidance, it seems that we should
> start from the assumption that it's not in scope for now given the fact that it's
> being sponsored by an AD as an Individual Submission.
> 

+1

> Regardless of whether that's the right path, or not, let's explore it as an
> option and see how the rest of the items identified in the proposed charter
> play out. Then we can leverage the outcome of the conversation to
> potentially revisit the fate of the base specification itself.
> 
> Given that guidance, here're the most obvious (and noncontroversial?) items
> needing to be done to shore up the proposed charter:
> 
These items make sense to me. +1

> specification from "Independent Submission" to "Individual Submission", so
> that's one down. I'll pull out my red pen on the other two topics and see if I
> can make them more reasonable.
> 
> Skipping ahead. . . here're the items that have previously been proposed as
> worth exploring in the setting of an IETF work group:
> 
> -----
> If I'm not mistaken, the Apps Area WG has already expressed an interest in
> this work. In that case, I believe that this WG would only need to track that
> effort and ensure that its work addresses the use cases required to support
> DMARC.
> 
> QUESTION: Given that it's an important topic, and there's no guarantee that
> the other effort will result in an applicable solution, would it still be
> reasonable to include a mention of this as worth exploration?
> If so, it'd probably make sense to reference the other work as a starting point
> to clarify we're not planning to spin up a competing solution.
> 

I personally think this is beyond the scope of the proposed working group even though the issue impacts DMARC. I suppose a mention might make sense but only in the sense of recognizing reality.

> -----
> * a mechanism for detecting abuse involving the <display-name> portion of
> the RFC5322.From field
> -----
> 
> contributors to the base DMARC specification to address this. The proposals,
> as you can see, didn't make it through to a consensus and it was suggested
> that they be brought to the broader community for consideration. It's highly
> likely that through the WG process we're able to identify a means by which
> this issue can be addressed.
> 
> base specification can be extended to apply the same level of "identifier
> alignment" to the <display-name> as is helping defend the <address-spec>?
> 

I think this is beyond the scope of the working group and probably stands on its own as a candidate for a separate working group. This is a much more intractable problem in that the display-name is free form.

> -----
> * a mechanism for mitigating the effect of failures of DMARC policy when a
> message transits a mailing list
> -----
> 
> I recognize that there's definitely a counter-pressure against including this
> topic as it seems to be a potentially quixotic quest. That being said, even if
> we don't find the perfect solution, it does seem reasonable to believe there
> is a way to provide something more than nothing that does help in some
> meaningful way. I'm not presupposing a solution, just that there have been a
> few possible options discussed at the edges which are likely to be worth
> more rigorous exploration.
> 
> QUESTION: Is there value in a WG such as this exploring possible solutions to
> this issue and developing guidance that would potentially help improve the
> utility of the base DMARC specification?
> 

I don't mind this topic being included but I'm not optimistic that a reasonable solution can be found other than "Dr., it hurts when I do that. Dr: Then don't do that!".

> -----
> * support for the notion of transitive trust (i.e., "host X trusted the sender of
> this message, and I trust X, so you should too")
> -----
> 

Definitely have an issue with this approach. It would significantly and negatively impact DMARC and almost introduce opportunities for abuse.

> I see this as similar to the above, but potentially more broadly applicable.
> One tweak I'd offer would be to replace ", so you should too" with
> something like ", so you could choose to as well".
> 
> QUESTION: Is there value in a WG such as this exploring possible solutions to
> this issue and developing guidance that would potentially help improve the
> utility of the base DMARC specification?
> 
> -----
> After over a year of deployment, and the rise in support services handling
> reports, many folks have suggested that it would be worth exploring how to
> offer additional optional means of transport for reports. The base DMARC
> specification provides for this, but it is an area that was left to be extended
> by a group such as this.

Definitely worth exploring.

> 
> QUESTION: Is this an area of exploration that is of enough interest to include
> in the charter for this proposed work group?
> 
> already proven useful in clarifying some options that aren't typically included
> in a base specification. For example, here a few items that may benefit from
> being specifically called out in the charter as worth
> exploring:
> 
> QUESTION: Do any items on this list seem to be worth specifically adding to
> the proposed charter as examples of the type of work that would be useful?
> 

+1 for the Using DMARC document.

> Finally, this list of potential work items was developed a while ago, and it's
> likely additional possible areas of exploration have surfaced since then. Are
> there any other substantive items that would be worth adding to the list?
> Keeping in mind, of course, that our first cut will be to assume that the base
> specification isn't in scope for now.
> 
> Once the dust settles a bit around these items, I'll take another whack at the
> charter text to at least get it stable for now. Then we can bubble up the
> bigger question and see if we can tackle that given the input I've seen
> recently on other threads.
> 
> Thanks again,
> Trent
> 
> 

Mike

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 16 Jul 2013 12:33:34 -0400

>to potentially revisit the fate of the base specification itself.

If the base spec is out of scope, I think the entire effort should be deferred until after it's done. I don't think it makes sense to spin up a working group to work on extensions until they can leverage a stable foundation. 

Scott K

---

From: Kurt Andersen <[email-masked]>
Date: Tue, 16 Jul 2013 16:35:20 +0000

On 2013-07-16 09:22 , "MH Michael Hammer (5304)" <[email-masked]> wrote:

>>sender of
>Definitely have an issue with this approach. It would significantly and
>negatively impact DMARC and almost introduce opportunities for abuse.

Did you perhaps mean to say ". . .almost *certainly* introduce
opportunities for abuse"? That would be my thought on the subject as trust
has rarely been transitive.

--Kurt Andersen
  LinkedIn

---

From: "Kelley, John" <[email-masked]>
Date: Tue, 16 Jul 2013 17:29:32 +0000

> starting point to clarify we're not planning to spin up a competing

+1 I agree with monitor and only address if needed.  A mention about the other work is fine.

+1 

> help improve the utility of the base DMARC specification?

-1 Not sure what continued debate here would accomplish.  

> help improve the utility of the base DMARC specification?

+1  I agree there is a potential value added for transitive trust.  I am not completely sold that a DMARC group is the place to hammer it out, but its probably worth discussing. 

+1  

> to the proposed charter as examples of the type of work that would be

None of those items are jumping out at me as something that MUST be part of the WG output.

> be to assume that the base specification isn't in scope for now.

Nothing comes to mind

> input I've seen recently on other threads.

John Kelley

---

From: Dave Crocker <[email-masked]>
Date: Tue, 16 Jul 2013 13:00:39 -0700

On 7/16/2013 9:33 AM, Scott Kitterman wrote:
> If the base spec is out of scope, I think the entire effort should be
> deferred until after it's done. I don't think it makes sense to spin
> up a working group to work on extensions until they can leverage a
> stable foundation.

Huh?

Given:

   1.  There is no community support for any proposals to change the
bits-over-the-wire.

   2.  The current bits-over-the-wire protocol is widely
deployed and is used for a very large fraction of the Internet's email
traffic.

Then if that does not constitute the ultimate form of "stable 
foundation", then I can't guess what you mean.

Please explain.

d/

---

From: Mike Jones <[email-masked]>
Date: Tue, 16 Jul 2013 22:19:46 -0700

+1 

> starting point to clarify we're not planning to spin up a competing

I think if it is expected to be addressed by another WG then only a reference to that work is appropriate.  I think even a mention of exploring it in this DMARC WG would be overreaching.

> "identifier alignment" to the <display-name> as is helping defend the

Yes, this would be a worthwhile discussion for a DMARC WG.  Maybe it is unlikely that a means to address this is identified as an extension to DMARC, but it's a real problem and worth the effort to discuss.

> help improve the utility of the base DMARC specification?

Yes, I believe so.

> help improve the utility of the base DMARC specification?

This one is a maybe for me.  I could see value in the discussion, but think it is far less likely a WG reaches any consensus on this than on the previous two items. 

> include in the charter for this proposed work group?

Yes. 

> to the proposed charter as examples of the type of work that would be

Yes to all of the items on the list from the "Using DMARC" document.

> input I've seen recently on other threads.

Thanks, 

Mike Jones
Agari
[email-masked]

---

From: Franck Martin <[email-masked]>
Date: Tue, 16 Jul 2013 22:46:48 -0700

> starting point to clarify we're not planning to spin up a competing
Isn't it the place where the BCP could answer that question, by giving guidance on how to do it pending a standard?

> "identifier alignment" to the <display-name> as is helping defend the

why not

> help improve the utility of the base DMARC specification?

This is a hot topic, and it smells a lot like qmail, but people will want to protect any domain. It seems rather to me the question is once a domain has p=reject what the miscreants do? Where the next protection should be put on? I'm not saying bad stuff happen through mailing lists, I'm saying bad stuff will happen to other domains (and there is a whole bunch coming up). It seems also to me we have the problem of defining what is a mailing list, in a similar way what is an organizational domain. Everyone knows when they see one, but not can define it in a machine parseable way.

> help improve the utility of the base DMARC specification?

is there transitive trust defined in other IETF documents?

> * When and how to use local policy override options

A lot of it is gained thru operational experience, common sense and level of threat. A BCP to help implementation whould answer a lot of these questions

> input I've seen recently on other threads.
I have the feeling that DMARC brings the subject of domain reputation and becoming stricter in what we receive. draft-ietf-appsawg-malformed-mail is a step in that direction, but may be we need to examine the problem more broadly of cousin domains and other forms of non direct domain spoofing. What are the tools we have today to handle them?

---

From: Barry Leiba <[email-masked]>
Date: Thu, 18 Jul 2013 14:25:01 -0400

...

> Then if that does not constitute the ultimate form of "stable foundation",
> then I can't guess what you mean.

Indeed.  Let's be clear:

I have agreed to AD-sponsor the DMARC base spec *if* I see significant
community review and support for publishing it as Proposed Standard.
I do need to see more reviews and more comments about whether it
should be a Standards Track RFC, but that's a separate point.

We have gotten some reviews of it so far, and those reviews have
suggested some changes.

None of those suggested changes -- including the ones Scott and John
have made in their reviews -- are, in my view, of a nature that would
invalidate the work that the BoF is meant for.  I believe that, as
Dave says, the DMARC spec is sufficiently stable to be a foundation
for the BoF, and for the discussion we'll have there.

Let's please focus on two things:

1. For the BoF, let's work on using the time productively, starting
with the assumption that something fairly close to the currently
published DMARC spec is where we jump off from.

2. For the DMARC spec, let's please have more of the IETF community
review the document, specifically responding to the questions of (a)
what technical changes are needed in it, and (b) whether it should be
published as a Standards Track specification.

Barry, Applications AD

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Jul 2013 19:10:11 -0700

> published DMARC spec is where we jump off from.

Let me press the distinction between 'editorial' document changes, 
versus changes to the bits over the wire.  With that distinction in 
mind, I believe that the BOF can start with the assumption that there 
will be no changes to bits over the wire.

This is always subject to change, but there's now an extended history of 
it's being true.

So the 'fairly close' is the editorial content of the latest draft.

> published as a Standards Track specification.

We have a review sequence lined up.  We suspended it after the first two 
because the call for editorial changes was strong enough and for enough 
change to make it worth letting further reviewers benefit from what we 
believe will be significantly improved readability.

FWIW, whatever queue of reviewers we've lined does not, should not, and 
of course will not, preclude anyone else from offering their own review. 
  More is better.

d/

---

From: Roland Turner <[email-masked]>
Date: Fri, 19 Jul 2013 17:25:17 +0800

> to potentially revisit the fate of the base specification itself.

I would suggest that this is a problematic approach because of the 
effective need that this creates for the charter discussion to correctly 
predict what the WG will come up with. The WG should work out what the 
WG comes up with, and should have as broad a remit as is feasible (give 
or take IETF process constraints) to do so. This is not to say that 
there should not be a recital acknowledging that the substantial 
installed base will necessarily limit changes - probably to nothing - 
but that seeking to constrain the WG's approach now, rather than during 
it, is likely to be harmful.

I'm thinking particularly about what happened recently with respect to 
the SPF macro facility and the fact that the discussion on removing it 
turned not on whether removing the facility was appropriate, but on 
whether the particular words chosen during chartering meant that this 
was, or was not, a permissible change for the WG to make.

- Roland

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Jul 2013 05:30:07 -0700

On 7/19/2013 2:25 AM, Roland Turner wrote:
> predict what the WG will come up with.

Given that there have been repeated queries to the community for 
technical work items and given that there have been no suggestions that 
have gained any traction, what is the basis for believing there is any 
work on the base spec for a working group to do?

With spfbis and similar efforts, they were started with a knowledge that 
refinements were needed, whereas for the dmarc base spec, we have no 
evidence of that need.  In fact, we have counter-evidence.

Working groups are expensive in time and effort.  They need 
justification before they start, not after.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 19 Jul 2013 11:23:37 -0700

> * Clarify how to address "backward compatibility" with the installed base.

Yes, yes, and yes.

> required to support DMARC.

<hat type="dmarc-participant">
That sounds right to me.
</hat>

<hat type="appsawg-co-chair">
My recollection is that there have been arguments made that the right place
to develop a solution to this problem is APPSAWG, but not that a decision
has been made that that's going to be the venue.  I've no objection, but I
don't recall a decision.

There are two proposals available as I-Ds that we can discuss someplace:
draft-levine-orgboundary and draft-sullivan-domain-policy-authority.
There's time on the APPAREA agenda right now if John and Andrew (or their
delegates) would like to lead a discussion about it.
</hat>

> starting point to clarify we're not planning to spin up a competing

The charter should say that the topic is out of scope, as we expect it will
be handled by another working group in parallel to our work.  If no working
group (extant or new) does pick it up, we can negotiate to recharter and
deal with it ourselves.

> "identifier alignment" to the <display-name> as is helping defend the

With the understanding that a working group can always decide not to tackle
an issue it's chartered to tackle because it decides the problem is
intractable, I think we should include it.  The ADs can encourage the
chairs to shut down a topic that it seems has no real solution sooner
rather than later.

> help improve the utility of the base DMARC specification?

Same answer as above.

> help improve the utility of the base DMARC specification?

Same answer as above.

> include in the charter for this proposed work group?

Same answer as above.

> to the proposed charter as examples of the type of work that would be

Given the path for dmarc-base on the table, I suggest these be omitted and
saved for some future dmarc-bis effort, except where operational advice can
be developed and included in the "using" document.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 19 Jul 2013 11:25:36 -0700

On Tue, Jul 16, 2013 at 8:50 AM, Dave Crocker <[email-masked]> wrote:

> choices.  I believe there isn't an IETF published paper in this realm, in
> spite of the issue appearing regularly.
>

RFC6377 devotes quite a bit of time to the topic, at least in the context
of DKIM.  There's also mention of ADSP, which is particularly germane here.

We may reasonably be asked what's different now since the publication of
that draft that would warrant reopening the topic.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Jul 2013 11:28:03 -0700

> that draft that would warrant reopening the topic.

I think the work we've discussed for this round might actually include 
proposing changes to mailing lists...

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 19 Jul 2013 11:29:52 -0700

> proposing changes to mailing lists...
And that's a reasonable answer.  :-)

-MSK

---

From: Greg Colburn <[email-masked]>
Date: Mon, 22 Jul 2013 11:36:40 -0600

Apologies for my tardiness to the conversation.  Comments below.

Greg Colburn

+1

>starting point to clarify we're not planning to spin up a competing

While the work required for this task is out of scope, it could
significantly impact DMARC.  This WG should probably track the effort as
closely as possible.

>"identifier alignment" to the <display-name> as is helping defend the

+1, we probably cannot solve it 100%, however, this WG seems like a
potential place to establish a wider effort.

>help improve the utility of the base DMARC specification?

+1, as we're heard through dmarc-discuss (and others) this is an issue
important to the community.  There is work to do here.

+1

>include in the charter for this proposed work group?

+1, as a large report parser, I'd love to +10 this one.  Absolutely things
to discuss here.

>to the proposed charter as examples of the type of work that would be

+1.  Using DMARC laid out a number of items to discuss further.