Subject: [apps-discuss] Review of draft-marf-spf-reporting-08

From: Glenn Parsons <[email-masked]>
Date: Tue, 13 Mar 2012 21:01:13 -0400

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
Document: draft-ietf-marf-spf-reporting-08
Title: SPF Authentication Failure Reporting using the Abuse Report Format
Reviewer: Glenn Parsons
Review Date:  March 12, 2012

Summary:
This draft is not ready for publication as a Proposed Standard and should be revised before publication
Major Issues:
This is a standards track document that is updating an experimental RFC.  And per the IESG Note in RFC 4408 that this is updating, there was quite a controversy on this 6 years ago.  As a result, I do not see how this can be published as a standards track update to the experimental RFC 4408 without some sort of discussion of the issues that led to the initial publication of the RFC 4405-4408 set.  This is especially the case since a 2 year timeline for deployment review was stated as part of the IESG note (and it has been 6 years).  If it is the case that SPF is stable enough to progress on the standards track then I would prefer to see RFC 4408 progressed to standards track before moving forward with these extensions as standards track.  Alternatively, if there has been no determination on SPF then it would be more appropriate for this document to have an experimental status.
 5.  The modifier "exp" is not the same as "explanation" in RFC4088.  If the intent is for this to be shorter, then a lot more explanation of that (including ABNF update) is required.
Minor Issues:
 3. Does the ABNF really have to be in hex?  That is why not ra instead of %x72.61
 3. The "include: mechanism" is vague.  Suggest adding a reference to clause 5.2 of [SPF] and/or using the same naming convention from RFC 4408 -- i.e., "include" mechanism

Nits:

** Downref: Normative reference to an Experimental RFC: RFC 4408 (ref. 'SPF')

 <http://www.ericsson.com/current_campaign>

GLENN PARSONS
Standards Advisor

Ericsson Canada
3500 Carling Avenue
Ottawa, ON K2H 8E9, Canada
Phone +1 613 667 1569
Mobile +1 613 796 9407
[email-masked]
www.ericsson.com

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 13 Mar 2012 21:33:34 -0400

On Tuesday, March 13, 2012 09:01:13 PM Glenn Parsons wrote:
> I have been selected as the Applications Area Directorate reviewer for this
> draft (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
> Please resolve these comments along with any other Last Call comments you
> may receive. Please wait for direction from your document shepherd or AD
> before posting a new version of the draft. Document:
> draft-ietf-marf-spf-reporting-08

This is not the current revision of the draft.

> This draft is not ready for publication as a Proposed Standard and should be
> revised before publication Major Issues:
> This is a standards track document that is updating an experimental RFC. 
> And per the IESG Note in RFC 4408 that this is updating, there was quite a
> controversy on this 6 years ago.  As a result, I do not see how this can be
> published as a standards track update to the experimental RFC 4408 without
> some sort of discussion of the issues that led to the initial publication
> of the RFC 4405-4408 set.  This is especially the case since a 2 year
> timeline for deployment review was stated as part of the IESG note (and it
> has been 6 years).  If it is the case that SPF is stable enough to progress
> on the standards track then I would prefer to see RFC 4408 progressed to
> standards track before moving forward with these extensions as standards
> track.  Alternatively, if there has been no determination on SPF then it
> would be more appropriate for this document to have an experimental status.

There is an SPFbis working group that has been chartered to deal with these 
issues.  The exact question of if it made sense to table this draft until 
SPFbis was disscussed in the working group and the conclusion was that it did 
not make sense to wait.

> 5.  The modifier "exp" is not the same as "explanation" in RFC4088.  If the
> intent is for this to be shorter, then a lot more explanation of that
> (including ABNF update) is required. 

Where do you get that it's not the same?  The draft says the source for exp is 
RFC 4408.

>  3. Does the ABNF really have to be in hex?  That is why not ra instead of

It's consistent with the related documents the working group has produced.

> 3. The "include: mechanism" is vague.  Suggest adding a reference
> to clause 5.2 of [SPF] and/or using the same naming convention from RFC
> 4408 -- i.e., "include" mechanism

This seems reasonable.
> ** Downref: Normative reference to an Experimental RFC: RFC 4408 (ref.

I think this is addressed.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Tue, 13 Mar 2012 21:50:28 -0400

> It's consistent with the related documents the working group has produced.

To be a little clearer and more useful:
The ABNF is done that way because literal strings in ABNF are not
case-specific, so using "ra" in the ABNF also allows "RA", "Ra", and
"rA".  How do we make it "ra", lower-case only, other than using hex?
We don't know how, and we've just used hex (it's in DKIM and other
docs as well).

It's icky, but there it is.

Barry

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 14 Mar 2012 11:13:50 +0900

> It's icky, but there it is.

What I have done in some instance (sorry, don't remember anymore what 
that was) was to say that we use ABNF, but without the 
case-insensitivity. If all the syntax is case-sensitive, that works. If 
part of the syntax is case-sensitive and the rest is case-insensitive, 
either way of using ABNF gets rather unreadable.

Regards,   Martin.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Mar 2012 19:54:19 -0700

On 3/13/2012 7:13 PM, "Martin J. Dürst" wrote:
> What I have done in some instance (sorry, don't remember anymore what that was)
> was to say that we use ABNF, but without the case-insensitivity. If all the
> syntax is case-sensitive, that works. If part of the syntax is case-sensitive
> and the rest is case-insensitive, either way of using ABNF gets rather unreadable.

That's a really good approach for getting mis-readings of the spec.

You are calling it thing but then re-defining it.  By saying 'ABNF' you invoke a 
set of knowledge and expectations.  Although you are no doubt diligent and 
proper in re-defining this one characteristic, readers are going to tend to fall 
back on what they already know about ABNF.

If it's that important to have a construct for 'case-dependent' strings, then 
define a new construct.

ABNF is extensible.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Ned Freed <[email-masked]>
Date: Tue, 13 Mar 2012 19:42:24 -0700 (PDT)

> >  3. Does the ABNF really have to be in hex?  That is why not ra instead of

That depends on whether or not you want it to be case-sensitive. "ra" is case
insensitive, %x72.61 is explicitly in lower case. See RFC 5234 section 2.3.

> It's consistent with the related documents the working group has produced.

I don't find that to be the case in either SPF or MARK documents, but even if
it is, I fail to see the relevance. This isn't a consistency of terminology
issue - the two different ABNF terminals are not different representations of
the same thing. So what matters is whether or not this particular terminal is
supposed to  be case-sensitive.

You're defining a new SPF record modifier here. RFC 4408 clearly states in
section 4.6.1 that modifier names are case-insensitive. So "ra" is correct and
%x72.61 is incorrect.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Tue, 13 Mar 2012 20:02:31 -0700 (PDT)

> It's icky, but there it is.

But this is an SPF thing, not a MARF thing. SPF semantics apply, and those
semantics say these strings are supposed to be case-insensitive.

				Ned

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 13 Mar 2012 23:05:31 -0400

On Tuesday, March 13, 2012 07:42:24 PM Ned Freed wrote:
> One small comment here:
> > >  3. Does the ABNF really have to be in hex?  That is why not ra
> > >  instead of> > 
> > > %x72.61
> 
> That depends on whether or not you want it to be case-sensitive. "ra" is
> case insensitive, %x72.61 is explicitly in lower case. See RFC 5234 section
> 2.3.
> I don't find that to be the case in either SPF or MARK documents, but even
> if it is, I fail to see the relevance. This isn't a consistency of
> terminology issue - the two different ABNF terminals are not different
> representations of the same thing. So what matters is whether or not this
> particular terminal is supposed to  be case-sensitive.
> 
> section 4.6.1 that modifier names are case-insensitive. So "ra" is correct
> and %x72.61 is incorrect.

That's a good point.  The related drafts I'd meant where the other MARF 
drafts, but I think I agree with you upon reflection.

Scott K

---

From: Glenn Parsons <[email-masked]>
Date: Tue, 13 Mar 2012 23:42:43 -0400

If the consensus is that you cannot wait ... my point is that given the IESG note in RFC 4408, it is not appropriate to make this standards track without an indication of the fact that RFC 4408 is being revised/elevated to standards track.  Now that note could be another IESG note...

BTW, would SPFbis would then subsume this RFC ?

On exp / explanation, I misread so that is not an issue.

And on the ABNF, my comment would apply to "ra", "rp" and "rr"

Cheers,
Glenn.

-----Original Message-----
From: Scott Kitterman [mailto:[email-masked]] 
Sent: March-13-12 9:34 PM
To: [email-masked]; Glenn Parsons
Cc: [email-masked]; [email-masked]
Subject: Re: [apps-discuss] Review of draft-marf-spf-reporting-08

On Tuesday, March 13, 2012 09:01:13 PM Glenn Parsons wrote:
> I have been selected as the Applications Area Directorate reviewer for 
> this draft (for background on appsdir, please see 
> Please resolve these comments along with any other Last Call comments 
> you may receive. Please wait for direction from your document shepherd 
> or AD before posting a new version of the draft. Document:

> This draft is not ready for publication as a Proposed Standard and 
> should be revised before publication Major Issues:
> And per the IESG Note in RFC 4408 that this is updating, there was 
> quite a controversy on this 6 years ago.  As a result, I do not see 
> how this can be published as a standards track update to the 
> experimental RFC 4408 without some sort of discussion of the issues 
> that led to the initial publication of the RFC 4405-4408 set.  This is 
> especially the case since a 2 year timeline for deployment review was 
> stated as part of the IESG note (and it has been 6 years).  If it is 
> the case that SPF is stable enough to progress on the standards track 
> then I would prefer to see RFC 4408 progressed to standards track 
> before moving forward with these extensions as standards track.  
> Alternatively, if there has been no determination on SPF then it would be more appropriate for this document to have an experimental status.

There is an SPFbis working group that has been chartered to deal with these issues.  The exact question of if it made sense to table this draft until SPFbis was disscussed in the working group and the conclusion was that it did not make sense to wait.

> 5.  The modifier "exp" is not the same as "explanation" in RFC4088.  
> If the intent is for this to be shorter, then a lot more explanation 
> of that (including ABNF update) is required.

Where do you get that it's not the same?  The draft says the source for exp is RFC 4408.

> instead of

> 3. The "include: mechanism" is vague.  Suggest adding a reference to 
> clause 5.2 of [SPF] and/or using the same naming convention from RFC

This seems reasonable.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 13 Mar 2012 23:56:27 -0400

On Tuesday, March 13, 2012 11:42:43 PM Glenn Parsons wrote:
> If the consensus is that you cannot wait ... my point is that given the IESG
> note in RFC 4408, it is not appropriate to make this standards track
> without an indication of the fact that RFC 4408 is being revised/elevated
> to standards track.  Now that note could be another IESG note...

The downref was discussed in the working group, there was consensus to 
proceed, and it was specifically noted in the last call announcement.  AIUI, 
that's all that's required from a process perspective.

On a practical basis, there is no chance that the changes proposed for SPFbis 
would affect the content of this draft.  It would be well outside the scope of 
the charter.

> BTW, would SPFbis would then subsume this RFC ?

It would be up to the working group to determine.  To fit into the existing 
charter, the WG would have to determine this was widely deployed.  By the time 
we get to discussing it, it may be (or maybe a small charter adjustment).  
It's hard to tell.
 
> On exp / explanation, I misread so that is not an issue.

OK.  Thanks.
 
> And on the ABNF, my comment would apply to "ra", "rp" and "rr"

Based on the other discussions in this thread I agree.  We should make them 
case insensitive and use the actual letters.  That's a simple enough change to 
make.

Scott K
> > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorat
> > e). Please resolve these comments along with any other Last Call
> > comments you may receive. Please wait for direction from your document
> > shepherd or AD before posting a new version of the draft. Document:
> > Alternatively, if there has been no determination on SPF then it would
> > be more appropriate for this document to have an experimental status.
> SPFbis was disscussed in the working group and the conclusion was that it
> did not make sense to wait.
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Ned Freed <[email-masked]>
Date: Tue, 13 Mar 2012 21:01:33 -0700 (PDT)

> That's a really good approach for getting mis-readings of the spec.

I have to agree. If I were on the IESG I'd push back *hard* on this.

> ABNF is extensible.

E.g., say that single quoted strings are case sensitive. That's a much better
approach IMO.

				Ned

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 14 Mar 2012 13:45:48 +0900

Hello Ned, Dave, others,

>> > What I have done in some instance (sorry, don't remember anymore

I found it: http://tools.ietf.org/html/rfc5147#section-3.

> I have to agree. If I were on the IESG I'd push back *hard* on this.

I half agree and half disagree. There is another case where we use ABNF 
with Unicode characters, not ASCII 
(http://tools.ietf.org/html/rfc3987#section-2.2). Although that's 
allowed by the ABNF spec, I'd guess most people will overread it at first.

>> back on what they already know about ABNF.

Or what they think they already know about ABNF.

> E.g., say that single quoted strings are case sensitive. That's a much

Good idea, I'll use that the next time I need it. I don't expect an 
update of RFC 5147 soon, nor do I have any other work around now that 
would need that feature, however.

Regards,    Martin.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 14 Mar 2012 09:11:23 -0400

> would affect the content of this draft.  It would be well outside the scope of

I'll note this:

1. Glenn has made his view on downgrading this doc to Experimental
clear, and it is a sensible suggestion.

2. Scott has noted that the working group did discuss this point, and
decided on Standards Track.

3. The IESG thus has input on the matter, and will ultimately decide
whether to make it PS or Experimental.

Others, whom we've not yet heard from, may certainly add their
opinions and reasoning.  But there's not much value to further
discussing it among those who've already spoken.

Barry