Re: [dmarc-ietf] Milestones changed for dmarc WG (public suffix exclusion)

2014-08-30 Thread Murray S. Kucherawy
On Fri, Aug 29, 2014 at 7:13 PM, Douglas Otis  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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Milestones changed for dmarc WG (public suffix exclusion)

2014-08-29 Thread Douglas Otis

On Aug 29, 2014, at 12:58 PM, Murray S. Kucherawy  wrote:

> On Fri, Aug 29, 2014 at 12:37 PM, Tim Draegen  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 (dbo...@ietf.org) 
> 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



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Milestones changed for dmarc WG (public suffix exclusion)

2014-08-29 Thread Murray S. Kucherawy
On Fri, Aug 29, 2014 at 12:37 PM, Tim Draegen  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 (dbo...@ietf.org)
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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Milestones changed for dmarc WG (public suffix exclusion)

2014-08-29 Thread Tim Draegen
On Aug 29, 2014, at 3:07 PM, Douglas Otis  wrote:
> 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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Milestones changed for dmarc WG (public suffix exclusion)

2014-08-29 Thread Douglas Otis

On Aug 29, 2014, at 11:06 AM, Pete Resnick  wrote:

> On 8/29/14 12:35 PM, Tim Draegen wrote:
>> On Aug 29, 2014, at 12:50 PM, Pete Resnick  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.
>>   
> 
> Are you OK with the following edits?
> 
> Dec 2014Complete draft on DMARC interop issues + possible methods to 
> address
> Mar 2015Complete draft on DMARC improvements to better support indirect 
> email flows
> May 2015Complete draft on DMARC Usage Guide
> May 2015Complete 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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc