Subject: [Gen-art] Gen-ART review: draft-ietf-marf-as-13

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Apr 2012 09:13:57 -0700

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-marf-as-13
Reviewer: Martin Thomson
Review Date: 2012-04-12
IETF LC End Date:
IESG Telechat date: (if known)

Summary: This document is fit for publication, though some minor
issues might warrant further consideration.

Major issues: None

Minor issues:

Reading through, this doesn't smell very much like an applicability
statement at all.  It has the distinct odor of a profile, or a set of
implementation/deployment/operational guidelines.  That might just be
me.

Section 4.2 doesn't really contain enough information for me to
determine when I might want to ignore your SHOULD.

Section 6.1, point 1 cannot be an interoperability requirement if
there isn't a mechanism provided.  The text is perfectly clear, but I
can't implement anything here to address the "MUST".  The problem is
that the reports are unsolicited, and therefore an out-of-band
"session" has not been established between providers. (Is an abuse
report the in-band solution you are looking for?  Yes, Section 7,
point 2, I know...)

Section 6.3, point 1 has the same complaint for the "SHOULD", though
in this case the softness of the "SHOULD" makes this more tolerable.

Nits/editorial comments:

Expand on first use: MUA, SPF, DKIM.

Parentheses around references is excessive ([CITE]).

Section 5.2, point 2 is a bit of a truism...MUST support optional
fields being optional.  Is it really necessary?

Section 6.3, point 3, sentence 2: missing comma after "([RFC3912])"

Section 6.4, point 3, did not parse: "reports are generated with use
by recipients not using"

Section 6.5, point 3 could be made MUST NOT by saying "MUST NOT reject
non-ARF messages based solely on the format" or by adding other
qualifications to that effect.  Obviously this has to allow for local
policy that rejects messages on other criteria, but you can make a
requirement like this.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 Apr 2012 19:14:17 +0000

> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: Friday, April 13, 2012 9:14 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Gen-ART review: draft-ietf-marf-as-13

Hi Martin, thanks for the review.

> implementation/deployment/operational guidelines.  That might just be

It is an Applicability Statement in the sense of Section 3.2 of RFC 2026.

> determine when I might want to ignore your SHOULD.

Some kind of out-of-band knowledge of an override address, or local policy, is what we have in mind here.  Of course, such out-of-band knowledge is likely an implicit part of the feedback solicitation agreement anyway, so really local policy is the only thing that might apply.  We can mention that explicitly.

> Section 6.1, point 1 cannot be an interoperability requirement if there
> isn't a mechanism provided.  The text is perfectly clear, but I can't
> implement anything here to address the "MUST".  The problem is that the
> reports are unsolicited, and therefore an out-of-band "session" has not
> been established between providers. (Is an abuse report the in-band
> solution you are looking for?  Yes, Section 7, point 2, I know...)

Existing implementations generally support this capability, but they all have different ways of doing so.  Thus, there's (currently) no standard way to do it.  Our ADs thus suggested the text that's there.

> Section 6.3, point 1 has the same complaint for the "SHOULD", though in
> this case the softness of the "SHOULD" makes this more tolerable.

The choice to deviate means the benefits described later in that point's text are lost.  That's the tradeoff.

> Expand on first use: MUA, SPF, DKIM.

OK.

> Parentheses around references is excessive ([CITE]).

Stylistic preference, I think.  :-)

> fields being optional.  Is it really necessary?

Hm, true.  I'll have to look at how that text evolved and figure out if it needs rewording or can just be dropped.

> Section 6.3, point 3, sentence 2: missing comma after "([RFC3912])"

Why?  It doesn't parse properly with that change.

> Section 6.4, point 3, did not parse: "reports are generated with use by
> recipients not using"

"with ... in mind" is the construct, but they are kind of far apart.  Will reword.

> policy that rejects messages on other criteria, but you can make a

I think a mix of the two makes sense: Leave it a SHOULD NOT, use your wording otherwise, and then describe valid deviation criteria as you've done.

Thanks; LC ends 4/24, will post a revision between that and the telechat.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Fri, 13 Apr 2012 17:05:45 -0400

Just one comment here; leaving the rest for Murray:

> It is an Applicability Statement in the sense of Section 3.2 of RFC 2026.

Indeed, and the problem is that we've used stand-along Applicability
Statements so infrequently in recent years that we don't seem to know
what they are any more.  Worse, we've often started to call them
"profiles".

I think an Applicability Statement is a normative document that does
not in itself define a protocol, but specifies how to *apply* one or
more profiles to solve a particular (set of) problem(s) or to perform
a particular (set of) function(s).  It might well be that we should
start calling many of the "profiles" that we do "Applicability
Statements" instead.

The advantage here is that the AS is a standards-track document, and
will progress along the standards track just as a Technical
Specification would.  Making it Information loses that aspect.

Barry, document shepherd

---

From: Martin Thomson <[email-masked]>
Date: Sat, 14 Apr 2012 05:58:43 -0700

> Specification would.  Making it Information loses that aspect.

It wouldn't make sense for this to be made informational.  There are
too many all-caps words.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 14 Apr 2012 06:16:26 -0700

Look, this really doesn't bother me that much.  But I can't even
imagine what a sensible implementation would do for these two points.
I don't like 2119 language that I can't see how to comply with.

Maybe I'm just not imaginative enough.

On 13 April 2012 12:14, Murray S. Kucherawy <[email-masked]> wrote:
>> isn't a mechanism provided.

It's the unsolicited case that bothers me here.  Is there some sort of
general advice that can be given on how to implement this for an
unsolicited report? Or are these existing implementations so radically
different that is tricky?  (That would be interesting in and of
itself.)

> The choice to deviate means the benefits described later in that point's text are lost.  That's the tradeoff.

Again, I'm less concerned with the why, but the how.

--Martin