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

[Scott Kitterman <[e-mail]>]

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.

> 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.

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.

> Minor Issues:

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

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.
> 
> Nits:
> 
> 
> ** Downref: Normative reference to an Experimental RFC: RFC 4408 (ref.
> 'SPF')

I think this is addressed.

Scott K