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

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
> 
> Cheers,
> Glenn.
> 
> 
> -----Original Message-----
> From: Scott Kitterman [mailto:scott@kitterman.com]
> Sent: March-13-12 9:34 PM
> To: apps-discuss@ietf.org; Glenn Parsons
> Cc: draft-ietf-marf-spf-reporting@tools.ietf.org; iesg@ietf.org
> 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/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:
> > 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
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss