Re: [spfbis] SPF and EAI

["Murray S. Kucherawy" <[e-mail]>]

On Thu, Jul 12, 2012 at 10:45 PM, Scott Kitterman <[e-mail]>wrote:

> We gain nothing from dropping it and we break a small number of existing
> records.
>

I don't agree that we gain nothing from dropping it.  We gain simplicity.
Perhaps the value of simplicity in a Proposed Standard is being
underestimated.


>
> It seems a bit odd that if we learned that as a lesson of the experiment,
> we
> didn't think important enough to mention in draft-ietf-spfbis-experiment.
>

Why would use of SPF macros be germane to a document whose function is to
compare adoption rates of SPF versus Sender ID, and not their specific
components?

As it happens, the data collection we did for that effort includes
something that's interesting to this one.  I don't think that's odd at all.

Because there's no compelling reason to remove it.


But there is.


> Did any of these precedents involve working groups where the charter said
> only
> unused features could be removed? If not, I don't think they are relevant.
>

Yes, all of them, since it's normal IETF procedure when upgrading the
status of something on the standards track.  You might want to review
RFC6410 Section 2.2, which covers advancement from Proposed Standard to
Internet Standard (Draft Standard has been eliminated since DKIM was
updated), as it includes as one of the criteria:

   (3) There are no unused features in the specification that greatly
       increase implementation complexity.

Macros are both relatively unused and increase complexity.  I'm trudging
through Section 8 in my review now.

The only "outs" here to me are the facts that (a) we're moving from
Experimental to Proposed Standard, which RFC6410 doesn't cover (although I
believe it's still useful to apply these criteria as good practice), and
(b) the definition of "unused" in this context is fuzzy.

I believe we have a stronger Proposed Standard by removing this or anything
else that yields no operational or community benefit.  Section 8 is not a
trivial piece of work for an implementer to follow and get right.  No, it's
not impossible, but I don't agree that it's at all straightforward either.


>
>    Changes to the SPF specification will be limited to the correction
>    of errors, removal of unused features, addition of any enhancements
>    that have already gained widespread support, and addition of
>   clarifying language.
>
> I don't think any of those apply here.
>
>
I don't agree.  The statistics speak clearly to me that macros are an
unused feature, and "removal of unused features" appears in the very
charter text you cited.

I've said my piece here.  Others will have to weigh in.  However, I ask
that the co-chairs open this as a new tracker item as a separate issue from
#14.

-MSK