Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 (was:Fwd: Eliot's review of the DMARC spec)

["Murray S. Kucherawy" <[e-mail]>]

On Fri, Jul 5, 2013 at 11:05 AM, SM <[e-mail]> wrote:

>  The details are further down in the document.  Section 5 is setting the
> stage for what comes later.  It's more overview than substance.
>
> I suggest not putting requirements in a section which provides an
> overview.  Barry and Pete commented about yelling in a WG.  I suggest
> taking those comments into consideration.    As a meta-comment about
> setting the stage I suggest writing the proposal as a mechanism.  You could
> then drop text, reorganize it, etc. to come up with a leaner version which
> specifies the mechanism and avoids the usual headaches.
>

I think requirements, or perhaps they're better stated as "goals", explain
part of how we got here.  They're useful for providing background.


>
>
>>   "Mail Receivers MAY deviate from a Domain Owner's published policy
>>    during message processing and SHOULD make available the fact and
>>    reason of the deviation to the Domain Owner via feedback reporting."
>>
>> I read the above as "if you do not do what I say you have to provide me
>> with a justification".  Let me rewrite the text:
>>
>>   "Mail Receivers deviating from a Domain Owner's published policy
>>    during message processing and MUST make available the fact and
>>    reason of the deviation to the Domain Owner via feedback reporting."
>>
>> If that text is not acceptable to mail receivers the RFC 2119 SHOULD will
>> have the same effect.
>>
>> SHOULD is appropriate.  There can be local policy reasons for not
>> revealing such details via feedback.
>>
>
> What I meant is that the proposal is telling mail receivers what to do.
>  The matter is entirely a local policy issue.
>  draft-kucherawy-dmarc-base-00 is intended as a Standards Track document.
>  The draft is doing policy stuff and trying to set conformance.  There has
> been previous similar efforts.  I would describe them as controversial and
> subject to interpretation.  I would scope the work to keep the
> implementation and policy parts separate so that you have a tightly-written
> specification.
>

I think your change of "MAY deviate" to "deviating" is fine, but changing
MUST to SHOULD won't work.  MUST is not appropriate because the protocol
doesn't completely break if you don't take the action described here, and
there are certain to be operators that won't do what's specified because of
a need to keep internal mechanisms private.  That fits SHOULD nicely.

Any standards track document "sets conformance" by spelling out those parts
that are mandatory to implement.  I don't understand the objection there.


>
>> In Section 7:
>>
>>   "When this is done, the DNS domain name thus recorded MUST be encoded
>> as an
>>    A-label, as described in Section 2.3 of [IDNA]."
>>
>> The above is under "policy enforcement considerations".  It should be in
>> a section discussing the DNS aspects of the specification.
>>
>> Why?  The context is the construction of an RFC5451 header field, not
>> something about DNS.
>>
>
> I guess that we are reading "policy enforcement considerations"
> differently.  The context is as what you wrote above.  What I was
> suggesting is to separate policy from how the DMARC code is supposed to
> work.  You could take the RFC 5451 approach to simplify the draft.
>
>
Every operational environment is different.  Some will be able to take the
RFC5451 approach and some will not.  Shouldn't we provide operational
advice for both cases?


>
>  Section 8.2 is about "Verifying External Destinations".  If I am not
>> mistaken, IETF specifications are not about imposing a specific method.
>>  Section 8.2 sounds like a tutorial for the implementer instead of a
>> definition of what the "DMARC policy string" means.
>>
>>
>> I disagree; a specification is indeed about describing a specific method.
>>  Tutorials for implementers appear throughout various documents we produce,
>> one of which you are working on in another working group right now.  :-)
>>
>
> I disclaim any knowledge of any other working group. :-)
>
> I have been reading some specifications (not mail-related) and some
> reviews recently.  I don't think that the Internet Engineering Tooth Fairy
> will agree with the following; sometimes a proposal specifies a method and
> gets into details which turns the proposal into a guide about a specific
> implementation.  A Standards Track document is about interoperability and
> not about specifying how the implementor should do things.
>

This sort of protocol isn't completely deterministic.  At various
junctures, there are places where operational decisions get made.  It
strikes me that guidance when making those decisions is a good thing, and
its absence would be a bad thing.  We are asked to provide it more often
than not.

I think it all comes down to whether separating that sort of material out
into a separate document is a useful thing to do.  If doing so would mean
an implementer needs to hop back and forth between two documents just to
get the thing running, I'd say we've done the implementer a disservice.

I'm going to leave the rest for now and see what you think of the next
version.  I think a lot of this has been addressed, though I'm sure there
will be other things to discuss.

-MSK