Subject: [dmarc-ietf] Milestones changed for dmarc WG

From: IETF Secretariat <[email-masked]>
Date: Thu, 28 Aug 2014 06:52:48 -0700

URL: http://datatracker.ietf.org/wg/dmarc/charter/

---

From: Pete Resnick <[email-masked]>
Date: Fri, 29 Aug 2014 11:50:43 -0500

> URL: http://datatracker.ietf.org/wg/dmarc/charter/

Tim/Ned [Ccing WG]:

While I think the milestones that appear in the wiki are great for 
internal WG management (and in fact I think you could even add more of 
them), I think for the external-facing milestones on the charter page, 
you should have the more common externally visible milestones like 
"initial draft of X" or "submission of completed document Y to the 
IESG", etc.

That work for you?

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Tim Draegen <[email-masked]>
Date: Fri, 29 Aug 2014 13:35:51 -0400

On Aug 29, 2014, at 12:50 PM, Pete Resnick <[email-masked]> wrote:
> Tim/Ned [Ccing WG]:
> 
> While I think the milestones that appear in the wiki are great for internal WG management (and in fact I think you could even add more of them), I think for the external-facing milestones on the charter page, you should have the more common externally visible milestones like "initial draft of X" or "submission of completed document Y to the IESG", etc.
> 
> That work for you?

Yes it does.  I'll rework the external-facing milestones to perhaps remove some confusion.
=- Tim

---

From: Pete Resnick <[email-masked]>
Date: Fri, 29 Aug 2014 13:06:01 -0500

On 8/29/14 12:35 PM, Tim Draegen wrote:
> On Aug 29, 2014, at 12:50 PM, Pete Resnick<[email-masked]>  wrote:
>    
>> Tim/Ned [Ccing WG]:
>>

Are you OK with the following edits?

Dec 2014    Complete draft on DMARC interop issues + possible methods to 
address
Mar 2015    Complete draft on DMARC improvements to better support 
indirect email flows
May 2015    Complete draft on DMARC Usage Guide
May 2015    Complete draft on changes to DMARC base spec

(That is, separating out the two documents from the May date, and 
rewording them a bit.)

If so, I can make the changes as I approve them.

pr

---

From: Tim Draegen <[email-masked]>
Date: Fri, 29 Aug 2014 14:10:43 -0400

On Aug 29, 2014, at 2:06 PM, Pete Resnick <[email-masked]> wrote:
> Dec 2014    Complete draft on DMARC interop issues + possible methods to address
> Mar 2015    Complete draft on DMARC improvements to better support indirect email flows
> (That is, separating out the two documents from the May date, and rewording them a bit.)
> 

Yes!

---

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Aug 2014 11:09:46 -0700

> May 2015    Complete draft on changes to DMARC base spec

Not clear to me what "draft on DMARC improvements..." means.  Is it a
spec, a design discussion, or what?

I'm also wondering about the implied overlap of work, cased on the close
proximity of the final milestones.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Ned Freed <[email-masked]>
Date: Fri, 29 Aug 2014 11:08:51 -0700 (PDT)

> If so, I can make the changes as I approve them.

Is "complete draft" the usual way these things are done now? It used to be
that you list WGLC, LC, RFC published for each.

I have to say I like this approach a lot better. Less bureaucracy.

As for the substance, it looks fine to me.

				Ned

---

From: Pete Resnick <[email-masked]>
Date: Fri, 29 Aug 2014 13:18:06 -0500

> spec, a design discussion, or what?

Good point:

Mar 2015    Complete draft specification on DMARC improvements to better 
support indirect email flows

> proximity of the final milestones.

The dates I will leave to the WG and the chairs to work out how they 
wish to manage.

pr

---

From: Pete Resnick <[email-masked]>
Date: Fri, 29 Aug 2014 13:23:34 -0500

> that you list WGLC, LC, RFC published for each.

Different groups do them different ways. I'm partial to just listing the 
"complete draft", since LC and RFC published are dependent on parties 
other than the WG. I take "complete draft" to mean "WGLC complete and 
submitted to the IESG".

The other thing I like about "complete draft" in this case is that it 
leave it to the WG whether to publish a particular draft or not. For 
example, I can imagine the WG deciding, "You know what: We're going to 
include enough of the discussion of interop issues and why we chose 
particular methods in the actual specification document, so there's no 
point in actually submitting the first draft as an RFC; it can just be 
an internal document." Or obviously the WG could choose to publish it 
because it *does* have important info for the community. Either way, you 
can make that decision independent of the milestone.

> I have to say I like this approach a lot better. Less bureaucracy.

Me too.

pr

---

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Aug 2014 11:19:40 -0700

On 8/29/2014 11:18 AM, Pete Resnick wrote:
> wish to manage

Merely as a possible tool for figuring out the major milestones, perhaps
the external choices should wait for the more detailed inward set of
dates?  Those will give a clearer sense of the wg focus on different
topics at different times.

d/

ps. I agree with Ned's comment about the benefit of keeping the public
milestones few and simple.

---

From: Tim Draegen <[email-masked]>
Date: Fri, 29 Aug 2014 14:29:55 -0400

> proximity of the final milestones.

The final milestones represent parallel work efforts -- and hopefully they're different enough from each other that they can progress independently.

One deals with operational best practice, the other with the tech spec.

---

From: Pete Resnick <[email-masked]>
Date: Fri, 29 Aug 2014 13:31:46 -0500

> topics at different times.

I do prefer to have *something* listed on the charter page now, even if 
those dates are spitballs and likely to be updated once the WG gets its 
legs under it. With the current tools, the chairs can update those dates 
any time they see fit without having to go back to the AD, so they are 
by no means set in stone (or even very wet cement).

pr

---

From: Douglas Otis <[email-masked]>
Date: Fri, 29 Aug 2014 12:07:21 -0700

> May 2015    Complete draft on changes to DMARC base spec

Dear Pete,

The charter statement indicates work on a public suffix concept is out-of-scope.  This is fine provided the definition used in the charter is retained:

"An organizational domain is the 'base' name that is allocated from a public registry;" 

With the "root" of domains being the top-most element, an organizational domain therefore exists immediately below that of the registry (or that of the registrar's domain).  Any other arrangement would create an unmanageable situation. 

Those playing the role of registering or as registrar is determined by assigned international organizations managing these functions.  While some may insist they should be able to offer some role of registrar to establish higher granularity for organizational domains, only those so authorized as a registrar can be recognized as playing that role.  This means only the defined organizational domain is able to subsequently increased granularity below their domain by way of their policy assertions.  Such policy assertions should be a matter handled within the WG as related to organizational domain policy.

Regards,
Douglas Otis

---

From: Tim Draegen <[email-masked]>
Date: Fri, 29 Aug 2014 15:37:35 -0400

> The charter statement indicates work on a public suffix concept is out-of-scope.  This is fine provided the definition used in the charter is retained:
[snip]
>  Such policy assertions should be a matter handled within the WG as related to organizational domain policy.

Hi Doug.  I'm not Pete but you're writing about the charter's scope and so I'll jump in.

Simply put, the public suffix concept is useful beyond what DMARC requires of it.  The best that DMARC can do (as a piece of technology) is fully articulate 1 specific use case for the public suffix concept, and hope that other use cases get fleshed out enough so that a viable solution can be crafted by something other than this WG.

The closest DMARC comes to discussing policy assertions between organizational domain policy and "everything below the organization" shows up in 1) the DMARC record discovery mechanism (that is, look at direct domain first and if nothing is there then look for a record at the "organizational domain") and 2) the DMARC options of "p=" and "sp=".   How number 1 and 2 are used in operation -- as it's not exactly clear to the casual reader -- can be captured and explored in the operational-facing Usage Guide document.  I hope this describes how the WG will tackle what you've brought up.

=- Tim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Aug 2014 12:58:11 -0700

On Fri, Aug 29, 2014 at 12:37 PM, Tim Draegen <[email-masked]> wrote:

> Simply put, the public suffix concept is useful beyond what DMARC requires
> of it.  The best that DMARC can do (as a piece of technology) is fully
> articulate 1 specific use case for the public suffix concept, and hope that
> other use cases get fleshed out enough so that a viable solution can be
> crafted by something other than this WG.
>

There's also a mailing list where this is being discussed ([email-masked])
as a thing independent of DMARC, and it was the subject of a BoF in Atlanta
(I believe) and at least a couple of APPSAWG presentations in the past, so
I expect it will get its own Working Group once there's critical mass and a
problem statement.  This WG should adjust (or be able to adjust) to use
whatever that group produces, but not go further than that.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Fri, 29 Aug 2014 19:13:40 -0700

On Aug 29, 2014, at 12:58 PM, Murray S. Kucherawy <[email-masked]> wrote:

> There's also a mailing list where this is being discussed ([email-masked]) as a thing independent of DMARC, and it was the subject of a BoF in Atlanta (I believe) and at least a couple of APPSAWG presentations in the past, so I expect it will get its own Working Group once there's critical mass and a problem statement.  This WG should adjust (or be able to adjust) to use whatever that group produces, but not go further than that.

Dear Murray and Tim,

While the PSL might be useful for offering some web related assertions, its current form is inappropriate for email policy.  Those working on the web/email related issues might hope these common concerns will engender enough synergy to formalize a published list of registrar domains.  Such a list would certainly minimize policy discovery overhead.  Unfortunately, something this simple is not likely being discussed.  A discussion that seems to be more behind closed doors.

Great care must be exercised to ensure DMARC policy does not create accountability gaps or overlaps.  The ONLY practical means this can be ensured is to use the definition made in the DMARC charter.  This means vendors offering services will need to "close" the gap between the domain they themselves registered, and that of the subdomain they offer customers.  Only the domain formally registered with a registrar must be considered authoritative.  There is simply no practical alternative for establishing an appropriate authority.  Authors of a PSL lack authority and have already created authority gaps and overlaps.

Regards,
Douglas Otis

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 30 Aug 2014 14:52:04 +0900

> support indirect email flows

Up to this point the discussion on the dmarc mailing list has focused
on alternative channels (Otis's TPA-labels, Kucherawy-Crocker's
DKIM-Delegate) for communicating authorization, not changes to DMARC.

Given that *all* of these specifications focus on authorization rather
than denial with the single exception of DMARC's p=reject/quarantine,
it's not obvious to me that improvements to DMARC are needed/feasible
beyond acknowledging existence of other authorization protocols to
which recipient policy may give precedence.

How about s/DMARC improvements/protocol improvements/ ?  If necessary,
a nod to "including changes to DMARC" could be added.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 30 Aug 2014 02:10:57 -0700

On Fri, Aug 29, 2014 at 7:13 PM, Douglas Otis <[email-masked]> wrote:

> While the PSL might be useful for offering some web related assertions,
> its current form is inappropriate for email policy.  Those working on the
> web/email related issues might hope these common concerns will engender
> enough synergy to formalize a published list of registrar domains.  Such a
> list would certainly minimize policy discovery overhead.  Unfortunately,
> something this simple is not likely being discussed.  A discussion that
> seems to be more behind closed doors.
>

This is old news, I think.  Nobody is advocating use of the PSL other than
as a temporary measure until a more robust solution is available.  Even the
DMARC base draft says so, and has for a very long time.

There's nothing happening behind closed doors here.

-MSK

---

From: Pete Resnick <[email-masked]>
Date: Sat, 30 Aug 2014 08:57:06 -0500

> a nod to "including changes to DMARC" could be added.

While I agree in principle, this is a distinction that is likely to be 
lost on people outside of the WG. "DMARC improvements" in the charter 
was meant to encompass possible changes to the DMARC spec, deletions 
from the DMARC spec, and additions to the DMARC spec (e.g., extra header 
fields in the message meant to indicate to implementations to do 
something different than the current DMARC spec says to do). I think 
most folks would understand all of those to be "DMARC improvements", 
whether or not they actually call out a change in the base spec.

We in the WG understand what we mean, and we can certainly be clear 
about it in the wiki. But I see no need for a change to the milestone text.

pr

---

From: Tim Draegen <[email-masked]>
Date: Sat, 30 Aug 2014 10:07:00 -0400

On Aug 30, 2014, at 9:57 AM, Pete Resnick <[email-masked]> wrote:
> We in the WG understand what we mean, and we can certainly be clear about it in the wiki. But I see no need for a change to the milestone text.

Almost had some crosstalk..

Stephen, the wiki is supposed to make this aspect clear, specifically "Phase 2".  If this isn't clear ("proposed specification changes"), we can make it so.

-= Tim

http://trac.tools.ietf.org/wg/dmarc/trac/wiki

---

From: [email-masked]
Date: Sat, 30 Aug 2014 08:20:32 -0700 (PDT)

> about it in the wiki. But I see no need for a change to the milestone text.

I'm in agreement with Pete. I also fail to see why people not familiar with the
group are going to spend time drawing conclusions from reading the milestones
in isolation, and in the unlikely event they do, why we should care.

				Ned

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 31 Aug 2014 15:26:46 +0900

Pete Resnick writes:

 > While I agree in principle, this is a distinction that is likely to
 > be lost on people outside of the WG. "DMARC improvements" in the
 > charter was meant to encompass possible changes to the DMARC spec,
 > deletions from the DMARC spec, and additions to the DMARC spec

My feeling is that the DMARC consortium would appreciate a change of
wording like the one I proposed, and I'm all for keeping them happy
and in the club.  If the distinction doesn't matter to others, why
not?

 > (e.g., extra header fields in the message meant to indicate to
 > implementations to do something different than the current DMARC
 > spec says to do).

Again, I don't think that wording is calculated to instill joy at
Yahoo!.  I think they'd be a lot more comfortable if it were in a
separate spec.  It would be better if they'd speak for themselves, but
AFAIK there are no Yahoo! or AOL reps hanging out here now.