Subject: [dmarc-ietf] Minor contradiction in the draft specification

From: "J. Gomez" <[email-masked]>
Date: Wed, 10 Apr 2013 22:31:23 +0200

I think there is minor contradiction in the draft specification of DMARC,
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1

Requirement #8 reads:

 Senders should be able to specify a percentage of their messages  
 to which their policies should be applied, with the rest  
 unaffected, in order to experiment and to understand and  
 minimize deployment risk.

And the first paragraph in section 7.1 reads:

 If the "pct" tag is present in a policy record, application of policy  
 is done on a selective basis.  The stated percentage of messages that  
 fail the DMARC test MUST be subjected to whatever policy is selected  
 by the "p" or "sp" tag (if present).  Those that are not thus  
 selected MUST instead be subjected to the next policy lower in terms  
 of severity.

I think Requirement #8 should be redacted to more properly fit with section 7.1, which by itself looks quite reasonable.

Regards,

J. Gomez

---

From: Steve Jones <[email-masked]>
Date: Wed, 10 Apr 2013 21:18:14 -0700

Requirement 8 reflects the earliest usage, where section 7.1 reflects the
"step-down" practice that evolved quite some time ago. I guess it's still
accurate for 2/3 of the cases? :)

Thanks for catching and pointing out the inconsistency.

On Wed, Apr 10, 2013 at 1:31 PM, J. Gomez <[email-masked]> wrote:

> I think Requirement #8 should be redacted to more properly fit with
> section 7.1, which by itself looks quite reasonable.
>
> Regards,
>
> J. Gomez
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Apr 2013 22:43:09 -0700

> accurate for 2/3 of the cases? :)

Technically speaking, we can't redact a requirement.  That's like altering
a purchase order to match what's being delivered.  Rather, it's left in
there as documentation of the evolution of the idea to what we ultimately
produced.

That said, he's right, the inconsistency is rather striking.

> Thanks for catching and pointing out the inconsistency.

+1.  Now we have to decide what to do about it.  Off the top of my head, I
suggest a parenthetical remark acknowledging the inconsistency and saying
materially what I've said here. Does anyone have a better idea?

-MSK

---

From: Steve Jones <[email-masked]>
Date: Thu, 11 Apr 2013 03:40:56 -0700

So maybe flagging any of the original requirements that were modified based
on subsequent deployment experience would be a useful thing to avoid
confusion - either in the reader's understanding, or in the impression that
the prior contributors were confused.  Perhaps add a sentence to the intro
to the section:

2.  Requirements

   Specification of DMARC is guided by the following high-level
   requirements, security dependencies, detailed requirements, and items
   that are documented as out-of-scope. Those requirements which were
   subsequently modified based on implementation experience have been
   indicated with _____.

Not sure if a reference to, in this specific example, section 7.1 would be
practical or you just add a "*" or something. Though without the reference,
how useful is it? "And then there's this requirement. Which we might have
tossed, or just changed in part. Figuring out which is left as an exercise
for the reader." ;)

No better idea here I'm afraid.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 11 Apr 2013 08:03:04 -0400

> materially what I've said here. Does anyone have a better idea?

Why can't we change it?  This is a new draft.  

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Apr 2013 06:26:59 -0700

> Why can't we change it?  This is a new draft.
The Requirements section, to me at least, documents the original set of
goals we set out to address with DMARC; it's a historical record of what we
wanted to produce, rather than an inventory of what we did produce.  It
seems fundamentally wrong to try to rewrite history.

I won't die on this hill if consensus is otherwise.  It just feels like a
pretty strange thing to do.

-MSK

---

From: "J. Trent Adams" <[email-masked]>
Date: Thu, 11 Apr 2013 09:08:21 -0600

Good catch... and +1 to Steve's suggested approach.

It seems to satisfy the "don't rewrite history" bit, plus it adds a
useful indication that one idea was tried, but experience tempered the
result (all without requiring lengthy discourse).

- Trent

On 4/11/13 4:40 AM, Steve Jones wrote:
> So maybe flagging any of the original requirements that were modified
> based on subsequent deployment experience would be a useful thing to
> avoid confusion - either in the reader's understanding, or in the
> impression that the prior contributors were confused.  Perhaps add a
> sentence to the intro to the section:
>
> 2.  Requirements
>
> Not sure if a reference to, in this specific example, section 7.1
> would be practical or you just add a "*" or something. Though without
> the reference, how useful is it? "And then there's this requirement.
> Which we might have tossed, or just changed in part. Figuring out
> which is left as an exercise for the reader." ;)
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On Wed, Apr 10, 2013 at 9:18 PM, Steve Jones
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Requirement 8 reflects the earliest usage, where section 7.1
>         reflects the "step-down" practice that evolved quite some time
>         ago. I guess it's still accurate for 2/3 of the cases? :)
>
>
>     Technically speaking, we can't redact a requirement.  That's like
>     altering a purchase order to match what's being delivered. 
>     Rather, it's left in there as documentation of the evolution of
>     the idea to what we ultimately produced.
>
>     +1.  Now we have to decide what to do about it.  Off the top of my
>     head, I suggest a parenthetical remark acknowledging the
>     inconsistency and saying materially what I've said here. Does
>     anyone have a better idea?
>
>     -MSK
>
>
>
>

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 11 Apr 2013 15:26:29 -0400

>pretty strange thing to do.

I don't see fixing a bug in the requirements as being fundamentally different than fixing a bug in the protocol. Since fixing the requirements be shouldn't affect implementation,  is should be easy to fix.

If the requirements are purely historical and not the requirements for the current effort, then I start to wonder why they are in the document at all.

Scott K

---

From: Franck Martin <[email-masked]>
Date: Thu, 11 Apr 2013 19:56:58 +0000

> If the requirements are purely historical and not the requirements for the current effort, then I start to wonder why they are in the document at all.

So we don't say go and read the archives :P

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 11 Apr 2013 15:59:39 -0400

On Thursday, April 11, 2013 07:56:58 PM Franck Martin wrote:
> >> On Thu, Apr 11, 2013 at 5:03 AM, Scott Kitterman
> >> 
> >> <[email-masked]>wrote:
> > I don't see fixing a bug in the requirements as being fundamentally
> > different than fixing a bug in the protocol. Since fixing the
> > requirements be shouldn't affect implementation,  is should be easy to
> > fix.
> > 
> > If the requirements are purely historical and not the requirements for the
> > current effort, then I start to wonder why they are in the document at
> > all.

Then I think they should reflect the requirements the spec is currently trying 
to support.  Historical requirements that aren't relevant to the current 
effort, um, aren't relevant.  Let's just fix it.

Scott K

---

From: "J. Gomez" <[email-masked]>
Date: Thu, 11 Apr 2013 22:16:10 +0200

On Thursday, April 11, 2013 9:59 PM [GMT+1=CET], Scott Kitterman wrote:

> > > > The Requirements section, to me at least, documents the
> > > > original set of goals we set out to address with DMARC; it's a
> > > > historical record of what we
> > > > wanted to produce, rather than an inventory of what we did
> > > > produce.  It seems fundamentally wrong to try to rewrite
> > > > history. 
> > > > 
> > > I don't see fixing a bug in the requirements as being
> > > fundamentally different than fixing a bug in the protocol. Since
> > > fixing the requirements be shouldn't affect implementation,  is
> > > should be easy to fix.
> > > 
> > > If the requirements are purely historical and not the
> > > requirements for the current effort, then I start to wonder why
> > > they are in the document at all.
> Then I think they should reflect the requirements the spec is
> currently trying to support.  Historical requirements that aren't
> relevant to the current effort, um, aren't relevant.  Let's just fix
> it.

I vote for fixing the requirement. This is to be a technical standard, whose internal consistency should be paramount over any historical traceability of its long past and generally vague guiding orders.

In my opinion, if the historical requirements are to survive unaltered in the RFC document, they should go at the end of it as an Appendix, and not at the beginning of the document.

Regards,

J. Gomez

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 12 Apr 2013 00:21:36 +0000

This sounds like a perfect candidate for a footnote (or the equivalent in IETF land). Make the change with a footnote indicating the contradiction in the original requirements.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Franck Martin
> Sent: Thursday, April 11, 2013 3:57 PM
> To: Scott Kitterman
> Cc: [email-masked]
> Subject: Re: [dmarc-ietf] Minor contradiction in the draft specification
> 
> 
> >> The Requirements section, to me at least, documents the original set
> >> of goals we set out to address with DMARC; it's a historical record
> >> of what we wanted to produce, rather than an inventory of what we did
> >> produce.  It seems fundamentally wrong to try to rewrite history.
> >>
> >> I won't die on this hill if consensus is otherwise.  It just feels
> >> like a pretty strange thing to do.
> >>
> >> -MSK
> >
> different than fixing a bug in the protocol. Since fixing the requirements be
> shouldn't affect implementation,  is should be easy to fix.
> >
> current effort, then I start to wonder why they are in the document at all.
> >
>

---

From: Tim Draegen <[email-masked]>
Date: Sun, 14 Apr 2013 20:55:13 -0400

> minimize deployment risk.

Nice catch!

After catching up on this thread, maybe 2 ways forward:

1. I'm not sure if this is possible, but it would be nice to strike the "with the rest unaffected" part and drop in a footnote explaining why it was done.

2. Maybe leave this as is, and put in a footnote after "with the rest unaffected" to reference how the requirement is met in section 7.1.

=- Tim