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

[Glenn Parsons <[e-mail]>]

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:[e-mail]] 
Sent: March-13-12 9:34 PM
To: [e-mail]; Glenn Parsons
Cc: [e-mail]; [e-mail]
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 
> 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