Re: [spfbis] SPF and EAI

[Scott Kitterman <[e-mail]>]

On Thursday, July 12, 2012 09:58:33 PM Murray S. Kucherawy wrote:
> On Thu, Jul 12, 2012 at 9:10 PM, Scott Kitterman <[e-mail]> wrote:
> > The charter says "removal of unused features".  This is different than
> > type SPF
> > because type SPF was redundant, this is not.
> 
> I think the issue of redundancy is inapposite.  It's an unused feature,
> pure and simple.  The statistics show far less less than 1% use.
> 
> Why do we need to keep something as complicated as macro expansion when
> almost nobody is using it?

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

> Perhaps more importantly: Why was it okay for us to decide Sender ID is de
> facto obsolete, while even stronger evidence (by orders of magnitude)
> against macros must be disregarded?  If it would help, I could add up the
> number of lines in sid-milter that added Sender ID support for comparison.
> It, too, was relatively small.

We didn't decide that.  It says right in the charter that Sender ID has been 
judged not to merit further development.  If some group has the energy to go 
work on SenderID and can get a working group chartered, more power to them.  
They'll first have to get some standards incompatibilities out of the way (and 
I don't think they can - this is discussed in the various appeals associated 
with it when it was published).  In any case, should Sender ID live or die 
isn't this working group's call and by whatever mechanism that was decided, 
it's irrelevant to the work of this group (the charter even says it had 
enjoyed wide scale deployment - deployment wasn't the issue).

> > I don't think it's in our charter to break existing, published SPF record
> > without a compelling case.  I don't think rarely used is at all
> > compelling.  I
> > don't think simplification is at all compelling either.
> 
> Purely from a procedural standpoint, I disagree.  SPF is currently
> Experimental, and moving to Proposed Standard is an ideal time to chop out
> things that fewer than two tenths of one percent of the deployed base is
> using.  That comprises part of what we learned from the experiment.  I
> don't agree that we are mandated to cater to such a tiny number of sites.

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.

>From a purely procedural standpoint you are right.  For largely political 
reasons it was put in Experimental.  The reason the charter is written as 
tightly as it is though is to keep people from using that excuse to break the 
protocol.  It's going from experimental to standards track, but it's not a 
normal case.

> The remaining question is whether the working group believes use by 200 out
> of 150,000 warrants keeping the feature.  To use your own argument, if in
> 5-7 years we've seen only this much use of SPF macros, I'm doubtful it's
> going to increase.

Because there's no compelling reason to remove it.  It's not unused and for 
whatever corner cases it is used for, I believe it's important (it's not easy 
to use well, so anyone who's using it does, I think need it).  While catering 
to corner cases isn't something we should focus on, I see no need to go out of 
our way to break them either.

> But, to be fair, we don't have a hard-and-fast definition of "unused" when
> going through this exercise, so it's left to consensus. Others will have to
> weigh in.
> 
> We do have precedent, however, as a guide.  For example, when DKIM went to
> Draft Standard, we chopped a few things (most notably "g=") because they
> had seen almost zero adoption.  According to the RFC4871 interoperability
> report, after 8.1M signed messages were processed, only 434 of keys were
> found that had "g=" tags in them.  So the use wasn't zero, and someone
> apparently found them potentially useful, but the decision was made that
> there was not enough adoption to warrant keeping the complexity in the
> specification.
> 
> However, we didn't remove "l=", much as we wanted to, because its use was
> around 3.7%.  Same with "x=" (3.4%) and "z=" (5.9%).  Use of SPF macros
> falls somewhere in between those and "g=".
> 
> There are other examples of this tactic going back as far as RFC821 (SAML
> and SOML).

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.

> You argued that the complexity isn't that big based on lines of code.  It
> wasn't for "g=" either.  I removed 162 lines of code that time from
> OpenDKIM, and we removed a small section of the RFC.
> 
> As is often quoted around these parts: "“Perfection is achieved not when
> there is nothing left to add, but when there is nothing left to take away."

I'm well aware of that, but nothing left to take away can be defined in 
different ways.  IMO, if (absent some really compelling evidence of which I've 
seen no sign) anyone has to go republish SPF records after we're finished we 
haven't lived up to the spirit of the charter no matter how finely people want 
to parse the words to claim we have.

   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 think the benefits of removal are almost entirely theoretical and the benefits 
of keeping macros in general and "l" specifically are very practical.  

Scott K