Re: [spfbis] SPF and EAI

[Hector Santos <[e-mail]>]

The premise that an documented feature in a specification is unused is 
now a basis for removal,  opens the highly subjective door to 
popularity contests and "Who's Who Using What" reasonings.  Case in 
point, the statement "its an unused feature, pure and simple" is not a 
fact.   If this premise is used across the board, I sincerely doubt we 
would have extremely wide support for (or it would be very hard to 
support) protocols when a "less popular" feature is always open for be 
subjectively removed and pulled from under your feet.  Fortunately, it 
hasn't and doesn't work that way.

I would prefer to discuss the proposal of removing a (SPF) feature on 
the basis there is a technical and/or security problem.  Odds are 
good, it is probably inherently less used anyway on that basis and 
IMO, worthy of discussion.

IMO, the issues with EAI appear to be complex, therefore unsettled and 
a moving target.

-- 
HLS

Murray S. Kucherawy wrote:
> 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
>