Re: [dmarc-ietf] PSD simplification

[Scott Kitterman <[e-mail]>]

On December 12, 2018 3:30:20 PM UTC, Dave Crocker <[e-mail]> wrote:
>On 12/11/2018 9:01 PM, Scott Kitterman wrote:
>> On Tuesday, December 11, 2018 08:17:38 PM Dave Crocker wrote:
>
>>> 1.  If the registry is to constrain which public suffix operators 
>>> are constrained to assert a default record, then I'll claim that's
>>> a false sense of security, given the range of unrelated and even
>>> more serious powers a parent domain can exert over a subordinate
>>> one.
>>> 
>>> 2.  If it is to avoid wasting a DNS a query to a record that won't 
>>> be there, that's false economy.  Most queries to the registry will
>>> fail. And most queries to both the From: domain name and its
>>> organizational domain already fail. The incremental cost of a
>>> wasted query to the organizational domain's parent is pretty
>>> small.
>>> 
>>> And the cost of creating and running a query-able database that is
>>> kept current is high and error-prone (as the existing PSL
>>> demonstrates.)
>....
>
>> I think your analysis is essentially correct, but I think point 1 is 
>> backwards.  Since (in the current draft), based on the registry
>> entries, the third level queries will usually not take place. It's
>> not that the PSOs are constrained not to publish records (they
>> aren't), it's that no one will (should) query for them based on the
>> third level test if they aren't in the registry.
>> 
>> This may seem like a small thing, but I believe it makes all the
>difference.  
>> You are certainly correct that nothing in an RFC can prevent a PSO
>from 
>> publishing such records.  What we can do is give guidance on when not
>to look 
>> at them.
>
>That's a cost-saving line of concern.  My point is that the existing
>mechanism already has quite a bit operational inefficiency from queries
>that fail, so that adding one more is a minor issue, especially as
>against the considerable administrative and operational cost of
>creating
>and running a registry.
>
>
>> I believe avoiding the privacy implications of the related feedback
>> are worth the transactional costs of the registry (but then I would,
>> wouldn't I).  I don't think a bad situation justifies making it
>> worse.
>
>Sorry but I don't know what privacy implications you are referring to.
>I don't even have a guess.
>
>And the draft makes no reference to privacy issues.  Or rather, the 
>Privacy Considerations section says the draft doesn't introduce any.

As written, it doesn't.  If you change it the way you propose, it will.

Scott K